Definition of a local coordinate system in function 'forces' causes crash of the calculation
Here after is the definition of a forces function with the declaration of a local coordinate system instead of CofR, like described here: https://www.openfoam.com/documentation/cpp-guide/html/classFoam_1_1functionObjects_1_1forces.html
{ type forces;
functionObjectLibs ( "libforces.so" );
writeControl timeStep;
writeInterval 1;
log yes;
patches ( "blade.*" );
pName p;
UName U;
rho rhoInf; // Indicates incompressible
log true;
rhoInf 1; // Redundant for incompressible
coordinateSystem
{
type cartesian;
origin (1.524 0 0);
coordinateRotation
{
type axesRotation;
e1 (-0.98480498 -0.17364769 0.00237365);
e2 (-1.73648178e-01 9.84807753e-01 0.0);
}
}}
It causes a crash of the calculation with the error here below:
--> FOAM FATAL IO ERROR: keyword origin is undefined in dictionary "/home/etudes/etudes_NP/ETR180036_NavalGroup_GrandChallengeIrene/01_helice_E779A/E779A_cyclic_MovingMesh/system/controlDict.functions.forces"
From function const Foam::entry& Foam::dictionary::lookupEntry(const Foam::word&, bool, bool) const
in file db/dictionary/dictionary.C at line 277.Looks like a bug.
Activity
assigned to @mark
In the meantime, you can also manage without the
coordinateSystemsub-dictionary since you don't need the type (cartesian by default). Eg,patches ( "blade.*" ); pName p; UName U; rho rhoInf; // Indicates incompressible log true; rhoInf 1; // Redundant for incompressible origin (1.524 0 0); coordinateRotation { type axesRotation; e1 (-0.98480498 -0.17364769 0.00237365); e2 (-1.73648178e-01 9.84807753e-01 0.0); }I personally prefer the style of encapsulated version that you originally used, however.
-
At the moment the
CofRis defined entirely via the dictionary file - either directly or with thecoordinateSystementry. This provides no means of having time-dependent changes in the origin other than physically changing the file and forcing an update, which would be a really horrible solution.To have a time-dependent coordinate, we'd need to expose write access to the coordinateSystem, which is easily doable. But how/where would you want to change this value? And how would we resolve inconsistencies in the values? Eg, You specify
coordinateSystemin the dictionary. During the calculation you modify its location, but then (for some reason) you have a re-read from the dictionary. The coordinateSystem would be that from the dictionary and not what you last specified yourself?/mark
Well, the solution you propose, such that:
origin (1.524 0 0); coordinateRotation { type axesRotation; e1 (-0.98480498 -0.17364769 0.00237365); e2 (-1.73648178e-01 9.84807753e-01 0.0); }is not working. The origin is well taken into account, but not the axes as indicated. The global coordinate system is still used. This is annoying..
About the time-dependent coordinate system, this latter changes only concerns postprocessing. I guess I can do something relatively clean and efficient using systemCall, and a command using sed and such.
By Poirier on 2018-06-19T12:52:42 (imported from GitLab project)
-
Sounds strange that origin is working, but you do not generate a
postProcessing/forces/*/localForce.datfile. Which branch are you using?Regarding time-variation: if you have reasonable idea of what you'd like to change, you can derived your own
timeForcesfunction object by inheriting from theforcesfunction object. I checked and the coordinate system is a protected member, which means you should be able to manipulate it as desired.If you get something that looks reasonable, and fairly generalizable, we can see about integrating it.
-
I did my non-exhaustive test with the 1712 master (last commit 73a83bf41ba0d, includes commit 19a01a62bb7d4).
Changed
tutorials/incompressible/pimpleFoam/RAS/wingMotion/wingMotion2D_simpleFoam/system/ControlDictand ran.The first entry of force:
(1.972338e+03 5.371971e+03 1.059305e-15)The first entry of localForce:
(-5.371971e+03 -1.059305e-15 1.972338e+03)So sign and directions flipped as expected. If I change the rotations again
e1 (1 1 0); e3 (0 0 1);The localForces rotate again. I don't know what is going wrong in your case.
Well, I have performed the same tests and I get the results results as you.
I realize that the coordinate system initially defined (which coincided with the global reference) remains taken into account throughout the simulation, despite the changes I make in the force function.
I thought this function was reloaded with every change I made to it.
By Poirier on 2018-06-19T14:00:58 (imported from GitLab project)
runTimeModifiable was set to true.
But my forces function is defined outside the controlDict, and called through a "#include"
OpenFoam seems to see that the forces function changes since this is displayed at every time step:
Re-reading object controlDict from file "/home/etudes/etudes_NP/ETR180036_NavalGroup_GrandChallengeIrene/01_helice_E779A/E779A_cyclic_MovingMesh_new/system/controlDict" because of modified file "/home/etudes/etudes_NP/ETR180036_NavalGroup_GrandChallengeIrene/01_helice_E779A/E779A_cyclic_MovingMesh_new/system/forces"Maybe do I need to write the force function explicitly in the controlDict?
By Poirier on 2018-06-19T14:11:44 (imported from GitLab project)
-
Sure, if your forces file is included, the file watch mechanism tracks it too. From what you report, it looks like you are either modifying it every time-step (eg, with a shell script), or your file-system is sticky and having issues. Presumably it is working as you wish, however the file header with the CofR will only be output once I think.
As you may figure, using the runTime modification mechanism will have a performance penalty if you are forcing disk access every iteration. There may also be some lag between when you make the change and it gets noticed. I would really encourage you to derive your own function object from forces and change the coordinate system there.
... Could also get a small support contract and get us to put it in, if that works for you too.
mentioned in commit b833ffec
mentioned in commit 71404067
mentioned in commit 1f0bc692
