If i solve an analysis, the check mark shows next to the analysis name, which to me implies that the results are ready.
If i then save the analysis, close it, and reopen it the check mark is replaced with the red sign, implying to me that the current results shown are not reflecting the current active set up for the analysis.
Practically speaking, this leads me to always wanting to re-solve an analysis when i reopen it after some time, because i wont risk looking at wrong/old results.
I suppose this is more a bug than a feature, but please educate me if the mistake is on my side.
As a side note, i’ve noticed that changing, say, a BC, and then changing it back to the same setup as the current showing results, will also replace the check mark with the red sign. I guess this could be a little more tricky to fix, but it would be a nice feature if the software was able to detect if the setup was the same as for the shown results.
I think that adding this check whether the setup is the same after changes (so you change something and then go back to the original setting) or not wouldn’t be easy and really needed. But keeping the green checkmark after saving, closing and opening the database would be nice.
Well, I am also bothered by this behaviour. The problem is a little bigger since multiple analyses can be prepared at the same time inside PrePoMax. So these status icons need another solution that would work.
Consider this situation. The user prepares a first model, runs the analysis named Analysis-1 and saves the model. Then prepares the second model, runs the analysis named Analysis-1 and saves the model. Now the contents of the .frd file represent the result of the second model. The user then opens the first model, sees a green checkmark at the Analysis-1 and uses right-click Results to load the results from the .frd file. The wrong results from the model 2 are loaded into the model 1.
I think the question is, what should this green checkmark represent? It was added to show that a running analysis was completed.
Hi!
I agree with you guys, for me the green checkmark should mean that there is a valid and consistent solution for the present or active model, that all the inputs at this moment are in correspondence with the actual solution file and there is no need to run the analysis again.
I hope that for example, if I modify a BC, change a material property, change a keyword, or perform any modification that as a result generate a new input file, the green checkmark becomes a red one, because the actual result file does not correlate with the new input file. That should be taken as a warning for the user that the actual result file is obsolete and does not match with the actual input file or model in PPM, and you have to solve it again. For me that’s the expected behavior.
But, for example, a simple BC renaming (just for clarity) in the GUI after a long solution transforms the status from a green checkmark to a red one, but no change has been made to the BC itself, like changing a displacement or rotation value for example.
In this example, I thought that the new name “SUPPORT_BASE” was used on the node set keyword in the input file, but for my surprise, only the name as a comment is used on the input file, and the original name with the “Fixed-1” was used as suffix in some entities (a node set and its reference in BC keyword), so, in my opinion no need to change to a red mark if a simple renaming was performed. Technically, because of the change in a comment **, the input file is different, but the input variables that define the model are the same.
Also, as Tor stated, if the solved model is closed and then reopened, the red checkmark appears. Even if no change in the model was performed. I tried to solve it at the beginning working with PPM organizing every *.pmx file in a specific folder and changing always the default “Analysis-1” name for clarity. One ppm file correlates with a unique *.frd result file always in the same folder (never in the Temp folder). But that does not solve the red checkmark after reopening the file, so my file management strategy is futile to maintain the green checkmark.
The situation stated by Matej could happen and agree that in this situation a red checkmark should appear if several pmx files (diferent models) have the same “Analysis-1” name and a common folder to store the result file is used (the default Temp folder for example). In that case, it is hard to identify to which pmx file correspond the actual Analysis-1.frd file, because they are overwritten with every solve. But, in this situation, if you open the last solved pmx file, should be recognized with the green checkmark instead of red, because the actual Analysis-1.frd in folder was generated using this model.
For me the green/red mark should represent:
That a valid *.frd file exist and correlates with the actual configuration of the *.pmx file. Maybe with the inclusion/reading of a unique “footprint” on the files (internal version??, random unique id??) that is updated if a change on the model variables is performed, excluding some changes like renaming an item on the model tree for example, or any change in the GUI that does not affect the information in the input file sent to the calculix solver.
I can only agree with the written words the problem is that the implementation of such behaviour would require a lot of work. I will think about how to make this green checkmark behave better.
Thanks @Matej for your support and dedication with ppm, just let us know if you need help to test this (or other) kind of functionalities under the most common situations.
I’ve given this some thought. Forgive this longwinded answer.
For me, the most important part of postprocessing is clarity. That’s why i enjoy prepomax so much, because it feels intuitive and productive, as opposed to some other pre and post options out there.
Not a seasoned FEA expert, i’ll take the liberty to reflect on what makes an ideal FEA software.
My own ideal workflow for any FEA software (this may be obvious to most):
CAD model import option when needed. Often i would be fine with manual node and element creation within the software for simple beam and shell models.
I then proceed to get a good mesh.
If its multiple bodies, i do a frequency analysis to test for rigid body motions and fix any issues that might show. If its a single part, i often skip this.
Linear static analysis with proper loads and BCs.
I then iterate over different types of mesh refinements, types of elements, BC’s etc., and compare the results from the different analyses, until i’m happy with the results, and feel they reflect the real physical problem.
Findings from the results may lead to a change in the model geometry, which are then tested in another run of the above steps. If internal model creation is possible, i duplicate it and make changes to the new geometry (say, add a beam element somewhere, to add structural stiffness). If not, i change it in the CAD model, then import the model, so i then have 2 different models in my project.
Finally, all of the results are stored for my personal documentation, and designers are informed of the needed changes to the CAD geometry used for manufacturing. My job is now done.
The above workflow demands a “trail of breadcrumbs” to be documented, and for that i would wish for PrePoMax to have:
Internal node and element creation (to avoid having to create beam/shell models in a CAD software)
Multiple meshes of the same and other element types, for the same geometry
A robust way to dynamically handle different analyses types, and model setups
Comparing the results with each other in 1 .pmx file
Some FEA software handles the “multiple setups” with the option to send “sets” to the solver. I wonder if it would be possible to simply add the picking of predefined sets to the Analysis → Edit window, as it seems the creation of an Analysis creates multiple .inp files anyways?:
Then being able to send all of them to the solver (i believe at the moment one can only send 1 at a time?):
Red sign: Not solved
Green checkmark: Solved
Green checkmark with yellow exclamation mark: Solved, but referenced .inp has changed since time of completion.
Bold means that the analysis is the one shown on the screen
Do you have any experience with Abaqus ? PrePoMax is based mostly on that software due to CalculiX using almost the same syntax as Abaqus. Thus, I would rather suggest following the way it’s handled in Abaqus to not confuse users with similarities to different software. In Abaqus, there are no such checkmarks (only job status: Submitted, Running, Completed, Terminated or Aborted) and you can have multiple models within a single database (they have separate containers in the model tree) but in PrePoMax it wouldn’t work since it uses a different approach with 3 tabs - for geometry, FE model and results. However, what could be implemented is the way Abaqus handles reruns. There you create jobs (like Analysis-1 in PrePoMax) and when you submit them, they use inputs from current settings in GUI. If you change something in the setup, you can still access old results but if you submit the same job again then the analysis will use new inputs. So you can have multiple jobs, with some of them containing results from previous runs with different settings and others containing results based on current settings. Of course, you may also have jobs for different models in the tree.
What’s more, in Abaqus it’s always possible to access the results of the currently running job if some increments were completed and thus output is partially written. You can also access the results if the analysis fails or is killed by a user but manages to complete some increments. In PrePoMax it’s more tricky. From what I’ve noticed, you can’t access the results when the analysis is running or when you kill it but you can open the results when the analysis fails to converge at some point. It doesn’t seem to be a limitation of CalculiX and its results files so it would be great if this behavior could be changed in PrePoMax.
Unfortunately not. What you’re saying makes perfect sense, if the vision of PrePoMax is to follow the layout of Abaqus, especially when CalculiX uses the Abaqus syntax.
Isn’t this kind of what PrePoMax currently does? Except there is no warning that anything was changed since the analysis was solved. If i solve the default analysis (Analysis-1), then create another analysis (Analysis-2), change something with the BC/loads, solve it, then the results from Analysis-1 gets a red mark, and right-click → Results responds with:
Which is quite unintuitive, and wrong, since the analysis DID complete.
I like being able to access old results, as long as it is obvious what the model setup was at the time it was solved (preferably shown in the GUI). At the very least, that it differs from the active model setup, if dependent on what is active in the GUI. That’s why i suggested the approach with sets, because i suspect it would mainly be a matter of changing how prepomax generates the .inp files send to the solver at the time of admitting the job, and it would be up to the user to set up the Analysis → Edit field with the correct sets. It’s a little fiddly, but quite transparent.
One could also see the benefit in importing an .frd results file to compare with an internally solved analysis, for which i think it should be clear that the results in the results tab have no connection to the project model.
Another thing; i think it would make sense if all solved results show up in the top results dropdown menu. As it is now, if i solve all 4 analyses from my example individually, but forget to click the “Results” tab in the CalculiX monitor windows, the results dont show up in the top results dropdown menu.
I am following the discussion and trying to extract the most important points. Maybe I could ask chatGPT to do it for me
We were using Abaqus a couple of years ago, and I think developers there made a lot of very good choices while designing the user interface to follow the responses of experienced FEM analysts. Following such a design is definitely a good way forward.
But it has some drawbacks.
The biggest problem at the moment is that after opening the .pmx file, all analysis states are changed to red. So I could take some .frd file metadata like date and length and save it with the analysis item when the results are first loaded. Then the state of the analysis icon would remain green no matter what happens with the .frd file. It would change to red only if the user changes the model.
Then I would add additional state icons to the results. One for the up-to-date results (green) and one for the out-of-date results (yellow). When the results tab is opened, the state of the results in .pmx model would be checked with regard to the .frd file. If the metadata is the same, the state would be green, and if not, it would be yellow.
This sound great @Matej, is like such a “footprint” that makes every .frd result file unique and linked to a specific .pmx file. I guess, that this could work as a first step to solve the problem that initiate this post.
In general, I agree that the PPM GUI should stay as simple as posible in terms of file management, but without losing its personal touch, adding features that makes it more attractive in terms of general usability, or expanding the main capabilities of Calculix.
