has anyone noticed issues that the history output names set in the model before it is run don’t show up in the .dat file (or only some them in this case). I am extracting the loads from a bunch of holes so it is nice to just process the .dat file but my nice tidy names aren’t coming working correctly.
thanks
Luke
History outputs are turned into *Node print, *El print and *Contact print keywords. They don’t have the NAME parameter so the names of the requests can’t be retained by CalculiX and only the name of the set is shown in the .dat file. However, PrePoMax keeps the names if you switch from the FE Model to the Results tab after the analysis submitted in GUI is completed.
I was testing this behaviour, and you are right. Sometimes the names get a little buggy. It is hard to explain everything going on with the selection procedure in the background to correctly prepare the selection sets to be exported to the .dat file in a way that it can be merged later in the results view.
I am thinking that the current implementation of history outputs is problematic. Namely, once the history output is created in one step (step-1), it can not be turned off (or am I missing something?) in the following steps (step-2). So despite the user creating no history outputs in the following steps (step-2), the results are outputted to the .dat file.
To solve this, once a history output is created in a step (step-1), it should be copied to all the following steps (step-2). This copy should be a dependent copy. This means no changes could be applied to the copies (step-2), only to the original (step-1). An additional tool to move the history output to a previous or to the following step would be needed. This would solve the naming issues and be more consistent with what is happening in the CalculiX input file.
A forgot how this is done in Abaqus.
The best solution is to define sets (node, element, surfaces) and apply history outputs to them. This should solve the issue with history output names.
Yes, history outputs are propagated by default. For example:
If no *NODE PRINT card is used within a step the selections of the previous step apply, if any.
But one can set the FREQUENCY parameter to 0 in a given step to suppress history outputs in it. However, I’ve noticed that PrePoMax accepts only values >= 1 for this parameter (“The frequency value must be larger or equal to 1”).
In Abaqus, there’s a History Output Requests Manager, among several other managers for step-dependent objects. It can be used to modify history output requests, deactivate them or move them between the steps. When a history output request is deactivated, its keyword is just removed from a given step definition.
It was naming the sets I ended up doing, that works just fine to extract the results based on that.
I also found it was wrapping the text so each result doesn’t come on the same line which is manageable but a little strange.
each line looks like this when I open the text file in Notepad++
total force (fx,fy,fz) for set RP14_ROT_480536 and time 0.1000000E+01
-7.389644E-13 -2.831069E-14 -2.273737E-13
That is also a really not very interesting result 
thanks
Luke
@FEAnalyst now I think that my idea of a dependent copy that can not be changed is not a valid one. What should be non-changeable is only the definition of nodes/elements. So the history output will have the same definition of nodes/elements in all steps but other features could change.
I was not aware of the frequency=0 option. Nice one. But if I remember correctly all history outputs and field ouputs in one step will have the same frequency. So no results will be generated in this case.
Currently, frequency keywords can be defined for each output. If they are different, the last one defined in a step is used. And it is propagated in the following step. That causes problems when checking which one will be used and what its value is.
Looking at the documentation, I think a better solution for the frequency keyword is the *Output keyword. As I understand, it has no actual output, but it can activate the Frequency parameter. So instead of having all history and field outputs with the frequency option (which can come into a collision), a more elegant solution is to include the *Output keyword into each step and control the output in one place. I will probably add a property to each step called Output frequency. If a default value is used, a frequency = 1 will be added in the step. Otherwise, the frequency will be set to the user’s defined value. It will be added at the beginning of the step data in the .inp file so it can be overwritten by some User defined keywords.
I remember that discussion from the Calculix forum: Different frequency for .dat file and *Node File - CalculiX
but I tested this on a simple case and it seems to be working fine, at least when there are 2 steps, 3 history outputs are defined in the first one and one of them is deactivated (by setting its frequency to 0) in the second step. The remaining history outputs either have FREQUENCY=1 or this parameter is simply omitted and the value of 1 is used by default. Here’s the syntax for the second step:
and the .dat file with the results:
Perhaps in more complex cases (like additional steps) it wouldn’t work properly. Or the aforementioned limitation doesn’t apply to the frequency of 0. Either way, I can ask Guido to fix that issue and allow for different output frequencies in the future. I’m collecting issues to report to him and now I have a few of them.
I tested some more variants and determined that only one frequency (larger than 0) can be used for all data outputs inside the step. The last one is used if more than one frequency parameter is defined. The frequency can also be set by using the *Output parameter and then omitting the frequency parameter by the data outputs. To disable any output individually, its frequency parameter must be set to 0. Using *Output, frequency=0 does not work.
So actually, the data output cannot be deleted in the following steps, only disabled (the correct way is frequency = 0). Once a data output is created, it should be copied to all of the following steps. Deleting it from only a couple of steps should not be possible. Only deleting all of its instances should be allowed.
