Saving Dynamic Data after Transients

protontim

I have a non-linear dynamic simulation I am running. It takes over three days to run using 14 cores (I will try using more in the future). The simulation completes, but it appears that it generates so much data that it crashes in the saving process. To avoid this issue I would like to only save the data for the last 1/3 of the run. I noticed that I can generate a list of time points for saving, and so accomplish my goal that way, but I was wondering if there was an easier way of telling the simulator to only save after a certain period of time has elapsed.

Victor

This isn't easier but might have some advantage -

You might be able to do it by defining two *STEP sections in the .inp file. The first step would do the 1st 2/3s of the time and have a high value for its FREQUENCY parameter to output only its final time step. The 2nd step would do the final 1/3 and have a lower value to output multiple time steps.

You can hopefully copy and paste all the step contents from the existing *STEP to the new one.

Haven't tried any of this. Just going by what the CCX manual says.

JohnM

What Victor said. This is an example that will run for 0.2s with no output, then run with output set by FREQUENCY for the remaining 0.1s. To make this input file, click "=" the look at the end of the input file. If your dynamic run is in "free fall", that is, not new loadings, the inputs are trivial.

protontim

I ran the simulation with saving just at the last 1/3 of the simulation using the method I originally described. It ran to completion, but then locked up when saving the data to disk. I let it run for a several days and it still didn't finish saving so something went whacky (it continuously to writes to disk and is using ~98% of my 128GB of memory). There is a great deal of data so I am not sure what the issue might be, or the failure point.

I greatly appreciate the suggestions and the supplied example - thank you. I will try that method in the next couple of days. If you all have any idea what might be causing the simulation to latch up during save that would be a real help. Thanks again.

Victor

Was that CCX or Mecway that got stuck writing?

If Mecway, you should be able to at least recover the CCX output file (.frd) from the temporary directory unless it's been cleared by exiting or restarting Mecway. Then perhaps access the solution from that .frd file without ever saving it as .liml.

I'm curious to know if there really is ~100 GB+ of data or something unnecessary is wasting resources. Did it leave a partial file you can check the size of?

protontim

I looks like the issue was with Mecway opening and saving the file. There is a 57.9GB .frd file in the temporary directory. When I try to open it with Mecway I see something very similar to what I saw when Mecway was trying to open/save the file. I have attached a screen capture of the task manager.

I will let it run for a while to see if it can finally load it, but so far it doesn't look very encouraging.

disla

¿Do you have any complex custom formula in the solution tree?

protontim

I am not familiar with the .frd format, but other than my time variant load, there is nothing extraordinary.

BTW it has been running for an hour plus and shows no sign of getting out of the state it is "stuck" in. I will let it continue to run, but this looks just like what happened before when I let it run for 3 days with no change.

Victor

Mecway likely needs more than twice the file size in memory to open a .frd file, so it sounds like the heavy disk usage is Windows swap trying to cope with insufficient RAM. In that case, it should eventually succeed but even if it does, the memory needed by Mecway to hold the solution may be too much and it would be pretty unusable.

Another way to reduce solution size could be to split it up into a different file for each solution variable and solve and postprocess them each separately.

JohnM

The frd file is usually a simple text file. if you look at the format, it should be easy to strip away the top two thirds of the solution to get what you've been looking for.

protontim

Thank you for your help. Looks like it eventually did load. Mecway is using about 44GB for the data. I was able to successfully analyze the results. Saved the file off in Mecway and the .liml file is about 69GB.

disla

Maybe related with this issue.

Same Model but one is set up in mmgs and the other in MKs. frd result for MKS is 7 times bigger. Another important difference is that MKS triggers mass scaling while mmgs not.

I know this is a ccx bug not Mecway but searching about it in the forum I found this could be an explanation.

By other hand it is well known ccx has some limitations dealing with large/small numbers. MKS is more prone to involve them. I would suggest again to switch from default MKS to mmgs inp.


@ Victor. Is there a way to say Mecway the frd is in mmgs units?. I have run .inp files with Scite and when opening the frd Mecway can't differentiate.