Fixed subcycling in implicit modal dynamic simulations

[boris-martin]

Partial fix to https://github.com/precice/calculix-adapter/issues/9 (which was first noticed for non-modal dynamic simulations) Tried on the perpendicular flap modified to have smaller steps than the time window size. (I tried 0.5 * window size and 0.2. Non-exact dividers like 0.4 might be worth trying too).

I'm still confused by the output frequency: in the current state, it outputs only once per time window instead of once per step, and there is no extra writes from removed iterations. I'm very confused by the role of iinc and jprint, and I can't tell if the write happens after the first step of an iteration or at the end of it. Investigation still ongoing.

Result-wise, it's quite convincing and seems to match correctly the result with bigger steps.

I also noticed that with subcycling I get one less VTK step outputted than with full steps.

[MakisH]

What would you like me to review, exactly? Because I still get a mesh failure in OpenFOAM (but I assume this is what you meant with "partial fix").

Using a timestep size of 3e-3 for the perpendicular flap, I get 163 steps. Applying a "warp by vector" (with displacement) filter on the CalculiX results (converted from FRD), the beam keeps getting longer, until it breaks down to an arbitrary shape.

I'm still confused by the output frequency: in the current state, it outputs only once per time window instead of once per step, and there is no extra writes from removed iterations. I'm very confused by the role of iinc and jprint, and I can't tell if the write happens after the first step of an iteration or at the end of it. Investigation still ongoing.

I remember trying a similar investigation for the OpenFOAM adapter, where I used the watch tool to monitor changes in the results files. Maybe that helps.

Result-wise, it's quite convincing and seems to match correctly the result with bigger steps.

Does this mean that this fixes #9? Because for me, it does not look like it.

I also noticed that with subcycling I get one less VTK step outputted than with full steps.

This worries me more. Maybe now CalculiX writes only in the beginning and not at the end? Maybe you can compare result files and see if they correspond at the same time.

I have not looked at the code yet, but I don't think I have enough knowledge of it to review it.

Edit: Looked at the code, I guess the main idea is to have separate read/write checkpoint functions for the modal analysis case, duplication which sounds like a source of future issues. But I understand that it may be needed here. Why not apply the same fixes for all simulations?

[boris-martin]

What would you like me to review, exactly? Because I still get a mesh failure in OpenFOAM (but I assume this is what you meant with "partial fix").

Actually, not that much now, mostly aesthetics (does it make sense to store the watchpoint in that data structure? Would a separate structure be cleaner ? Etc)

Using a timestep size of 3e-3 for the perpendicular flap, I get 163 steps. Applying a "warp by vector" (with displacement) filter on the CalculiX results (converted from FRD), the beam keeps getting longer, until it breaks down to an arbitrary shape.

Does this mean that this fixes #9? Because for me, it does not look like it.

Did you run a modal simulation? (run.sh -modal) Because the regular simulations are not fixed yet (hence the partial fix). Both kind must be fixed but this one is slightly easier (I've worked more on it, and the file is only 2000 lines long instead of 4000 :see_no_evil: ), which is why I'm starting on this side. But fixing non-modal dynamic (i.e. regular) simulations will take another PR.

I'm still confused by the output frequency: in the current state, it outputs only once per time window instead of once per step, and there is no extra writes from removed iterations. I'm very confused by the role of iinc and jprint, and I can't tell if the write happens after the first step of an iteration or at the end of it. Investigation still ongoing.

I remember trying a similar investigation for the OpenFOAM adapter, where I used the watch tool to monitor changes in the results files. Maybe that helps.

I don't quite understand the approach. What would I gain compared to logging the times where the frd() function (the only one writing output) is called?

I also noticed that with subcycling I get one less VTK step outputted than with full steps.

This worries me more. Maybe now CalculiX writes only in the beginning and not at the end? Maybe you can compare result files and see if they correspond at the same time.

First steps are matching but an extra step is added.

I have not looked at the code yet, but I don't think I have enough knowledge of it to review it.

An opinion of @KyleDavisSA would indeed be welcome.

[MakisH]

You are right, I forgot to enable the modal simulation mode. In that case, it looks like it solves the issue! :smile:

I don't quite understand the approach. What would I gain compared to logging the times where the frd() function (the only one writing output) is called?

Probably none. Indeed, different approaches are easier in this case.

[boris-martin]

I've got a running draft of a change that solves the output issue. Since we can't override previously written output, I started storing intermediate results, then at the end of a time window that converged (precicec_IsTimeWindowComplete()), we write all the stored results at once. If the time window is started again (a checkpoint is read), then we clear the buffer.

Since CalculiX is pretty much a blackbox in terms for understanding the output code, I designed a flexible buffer to handle changes if needed, as I didn't know exactly what had to be stored. The code is still a bit messy, and I'd like some conceptual approval on it before investing time on polishing the details.

This buffer code should be reusable for the non-modal dynamic code later :)

[boris-martin]

Regarding the big picture, I think the need and mechanics of the OutputBuffer need to be better documented.

I see how its internals should be documented, but where would you document the need? Inside the dyna_precice.c code ? That's actually why I left the commented frd call, to remember its "old location", but it's probably a good idea to put more text there.

[MakisH]

Regarding the big picture, I think the need and mechanics of the OutputBuffer need to be better documented.

I see how its internals should be documented, but where would you document the need? Inside the dyna_precice.c code ? That's actually why I left the commented frd call, to remember its "old location", but it's probably a good idea to put more text there.

I would just write a few lines at the beginning of the OutputBuffer.h.

[boris-martin]

I did some refactoring & documentation. I still need to maje changes related to Calculix's configurable input frequency, but the Buffer code seems ready to me.

[KyleDavisSA]

I tested this PR for the perpendicular-flap case with various sub-cycling. If I remember correctly, it was failing when one time step was not a multiple of the other. I had no problems this time around. Am I remembering this correctly.

Also, where can I find an example for the modal dynamic case?

[boris-martin]

This should produce a correct output with all step sizes, but with visualization artifact (at least in ParaView with ccx2paraview as converter), as every outputted thing is seen as a unit step.

Modal case is the perpendicular flap with ./run.sh -modal