effective deltaT or old time for lumpedPointMotion

As discussed off-line with @Taka, it would be useful to also record information about the update period to pass through to the FEM code.

Eg, Instead of the forces.out containing this

// Time index=421 value=0.08421 

points
...

it would be useful to have it contain

// Time index=421 value=0.08421 updateInterval=0.004

This is because the OpenFOAM mesh update interval can be controlled by just about anything (timeStep, cpuTime, clockTime) and the FEM code has no convenient way of obtaining this information, other than having its own internal cache.

Taka provided modify_force.out_file.pdf in the explanation.

Hi @Taka

I've looked through the code and it would not be a large change needed (a few lines in lumpedPointMovement.[CH] and lumpedPointDisplacementPointPatchVectorField.[CH] files).

However, while looking at the code changes (and deciding on output names), it seems that the most reliable naming would be something like this:

For plain output:

# Time index=421
# Time value=0.08421
# Time prev=0.08021

For dictionary output:

// Time index=421
time       0.08421;
prevTime   0.08021;

I think that having deltaT might be misleading (looks like we might mean the current deltaT from the CFD, instead as from the FEA).

So the solution essentially means adding a cached value to the boundary condition (to remember the last write) and pass this to the forces.out writing. Would it not be just as easy to cache the same value in the FEA solver??

Dear Mark

Let me confirm,

According to your explantion, [deltaT]=[time]-[prevTime].

Is my understanding correct ?

Sorry, I don't perfectly understand about their FEM solver.

But, according to their explanation, In the future, when doing calculations using an HPC machine (like a K-computer), "timeout" may cause calculation to forced terminate. Then, the deltaT information does not remain on the FEM tool side. When it would be necessary to do restart calculation, it is needed to get deltaT size. Therefore, it is ideal that the deltaT is on force.out file, they say.

"timeout": HPC ( like a K-computer) has roule that user has limit of time for one job. If the Job exceeds the time limit, it will be forcibly terminated.

Regards, Taka

OK that makes perfect sense

Hi Mark

Again, Is it correct ?

According to your explantion, [deltaT]=[time]-[prevTime].

Is my understanding correct ?

Yes, that would be the effective deltaT from the viewpoint of the FEM. The FEM side could read both (time and prevTime) and figure out their deltaT.

I think that we probably don't need the time index at all. What do you think?

Yes, I think so. Their request is to add information of delta-Time of FEM solver, only.

Regards, Taka

and customer has agreed your idea.

Hi @Taka

I'm not entirely happy with what I have. The modified code outputs time and prevTime as discussed, but I can work out a good way for the restarts to occur cleanly.

Assuming we run OpenFOAM and the FEA solver for a while, and produce this type of output forces file:

// I have given large numbers here to make it clearer to discuss
time       900;
prevTime   890;

On a later restart (after a timeout, or re-running the case), we don't have anything meaningful to do with the prevTime value. We would normally stash this type of information as part of the boundary condition itself, but we can write 'forces.out' at a much different frequency than we write any of the OpenFOAM fields. This means that a value recorded within the boundary condition will be different than in the forces.out file. On the other hand, it is difficult to imagine a proper restart without actually using the boundary condition.

For example, assume we save our fields every 200s and write forces every 10s. And assume the simulation timeout occurs at 902s. Then the last fields might be written at 800s (with prevTime = 790) but the forces file would have been written at 900s (with prevTime = 890).

If the restart is from 800, the FEA would have to wait for a new forces file to be written, otherwise it would have the wrong values.

There might also be some slight internal bookkeeping issues with the value of prevTime. If this is updated each time the forces file is written, but before the fields are written, we could have the funny situation that the prevTime is the same as the current time (and the restart information looks quite strange).

Hello Mark

Do you means that we should be do restart calculation from correct time step result ?

"If the restart is from 800, the FEA would have to wait for a new forces file to be written, otherwise it would have the wrong values."

I think this is something users should understand as a care point. It would be acceptable for user. And, I will explain this care point to the users.

Regards, Taka

mentioned in commit d3f7f91f

Hi @Taka and @alsdia

I just pushed a lumpedPoint-restartTimes-issue1793 branch which is based directly off of the master (2006) branch, but you can cherry-pick to any 2006 version.

I think that it does what is needed. The boundary condition now remembers when the output has occurred, which makes that available for restarts.

The comms/log file shows this type of information:

########
# Time value=0.0040986864
# Time prev=0.0031007136
# size=11
# columns (points) (forces) (moments)
# scaling points=1 forces=1 moments=1
########

The comms/forces.out this type of information:

////////
time            0.0040986864;
prevTime        0.0031007136;

The field output at 0.00436783/pointDisplacement contains this:

building
{
    type            lumpedPointDisplacement;
    controllers     1(vertical);
    dataWritten     (0.0040986864 0.0031007136);
    value           nonuniform List<vector> 0;
}

Please give it a try and let me know if it fullfills the requirements.

Hi @mark @Taka

compiled the code and tested lumpedPointMotion/building on my machine. No issues found. I think it fullfills the requirements.

Running simpleFoam (12 processes) 
Making dependency list for source file building-motion.C
[...]
Running ../code/building-motion 
Running pimpleFoam (12 processes)      

vi ./transient/comms/forces.out

////////
time            0.0091055063;
prevTime        0.0080930397;

Thank you. I will share the code to the customer.

mentioned in commit ea2e24b6