Introduction of categories

Dear CalculiX users,

We’ve added several new categories to the forum to be able to better group topics and help new users to get started. The following categories are available:

Official Announcements

Official announcements regarding CalculiX releases, important notices, and forum updates. Only admins and moderators can post, but anyone can reply.

Getting Started

Questions from new users about installing (Linux, Windows, macOS), running, and understanding the basics of CalculiX, input files, and simple analyses.

Examples/Tutorials

Example models, step-by-step tutorials, reference cases, practical advice, workarounds, best practices and learning resources for CalculiX.

Model Setup

Defining geometry, meshes, materials, boundary conditions, loads, steps, and preparing input files for analysis.

Analysis Issues

Errors, warnings, convergence problems, performance issues, unexpected results and questions related to the CalculiX solver during execution.

Advanced Features

Nonlinear analyses, contact, dynamics, thermal and coupled problems, user subroutines, and advanced element or material models.

CalculiX GraphiX

Questions and discussions related to CalculiX GraphiX (cgx): geometry creation, meshing, scripting and visualization.

Postprocessing/Visualization

Viewing, extracting, and interpreting results from CalculiX output files (.frd, .dat). Focus on understanding results and troubleshooting output data, not on configuring external tools.

Tool Interfaces

Using CalculiX with external software and workflows: meshing tools, preprocessors/postprocessors (e.g. ParaView, FreeCAD, Gmsh), scripting, automation, HPC, co-simulation, and pipelines.

Code Development

Discussions for contributors and developers working on the CalculiX solver codebase, including feature requests.

Please help us out by re-categorizing your existing topics. We’ll also try to do this manually, but it may take some time.

The categories were chosen based on the existing topics in the forum. We’d like to keep the total number small, but we’ll see how the current concept works out in practice.

Thanks & Regards,

Lukas

2 Likes

Let me know if you need some help. There’s indeed a lot of work, but should be worth it to make the forum more organized.

I think that some questions about issues with user’s cases can fall into multiple categories. Maybe something like this would be better:

  • Official Announcements

……………………………………….

  • Installation and Compilation

  • General Analysis Questions

  • Tips and Tricks

……………………………………….

  • CalculiX GraphiX

  • Third Party Tool Interfaces

……………………………………….

  • Bug Reports

  • Feature Requests

  • Code Development

1 Like

Thanks for your feedback!

From the description the categories should be fairly unique. But I‘ll practice a little with existing topics and see if this works out or whether there are redundancies or something is missing.

1 Like

How to do that?Is there a way I can help?

I have acces to my posts but I can’t find the way to re-assign it to a category?

You can only do it when creating new threads. You can’t edit the old ones anymore.

Btw. it would be really good to have a category for bug reports so that they don’t get lost on the forum.

1 Like

Thanks for pointing this out. It looks to me like this should be possible by changing the community settings. We’ll give it a try later.

Regarding the bug reports category, I propose the following logic:

  • Unexpected behaviour (possible bugs) should get the “Analysis issues” category.
  • As soon as the bug is confirmed/discussed by other users, a GitHub issue should be created linking the Discourse topic (I admit GitHub issues are not well moderated at the moment, but it’s also something on our todo list)
  • On GitHub it’s easier to keep track of bug reports and proposed code changes via pull requests (another todo)

The motivation is to keep discussions about functionality and code behaviour separated from actual issues such that, in a way, GitHub issues will be the bug category (in fact not only for bugs, but also e.g. for confirmed feature requests, corresponding labels can be assigned).

I know we’re not there yet…

We’re very much appreciating your support in this forum and we’re thinking about more transparent guidelines to further encourage community contributions to this project.

Speaking about that, IMO the main improvements within the GitHub issues should be:

  • adding Bug and Feature labels (maybe also other labels) - like what we do within FreeCAD’s repo
  • turning this user’s many issues into a single issue (or forum thread here) with multiple comments and asking him to add new ones this way so that the repo is not crowded with information about projects using CalculiX and so on

True. For FreeCAD, we also have a forum section for bug reports when someone can’t or doesn’t want to use GitHub. Then mods create a GitHub issue, link it with the forum thread and archive the thread.

When it comes to PRs, it would be awesome if someone could review and merge them. It seem that Guido is implementing everything manually atm. My large PR with typo fixes for the manual will likely stay in the queue for quite some time.