[LM4112]

Good morning all

I have a doubt regarding how OpenFOAM reads the units. For example the velocity is always [0 1 -1 0 0 0 0], it doesn`t matter if I use meters or millimiters. Only the initial value (the number I mean) changes. Is it correct?

[Lieven]

Hi Luca,

In principle OF can work with any system of units but by default it uses the SI units.
But it is pretty easy to deviate from it. The only thing you need to be aware of, is that you need to change the values of constants accordingly (e.g. viscosity in mm²/s instead of m²/s).

Have a look at http://www.openfoam.org/docs/user/basic-file-format.php for more information.

Cheers,

Lieven

[LM4112]

Hi Lieven, thanks for the fast reply.
Then I have to change only the "numbers". I mean if I use mm instead of m I have to scale each value that concerns the length (for example pressure, velocity etc..) and I am not supposed to touch the numbers between the brackets that identify the dimension (for example the velocity is still 0 1 -1 0 0 0 as it means length per time and not meter per second).
I guess that the values are just "numbers" for the solver. They just have to be consistent. Do you agree?

[Lieven]

Yep, that's how I see it.

But just to give you my opinion, if there is no reason except for 'convenience' to deviate from SI units, I would not do it. The chance you make errors with it are relatively big (especially with respect to post-processing).

Cheers,

Lieven

[LM4112]

the problem is that my mesh is in mm, then I want to convert all the values in mm instead of convert the mesh in meters (that in my case is much more time demanding)

best regards,
Luca

[colinB]

what kind of mesh do you have?

if it is a blockMesh mesh you have the entity convertToMeters
in the very beginning where you can choose the dimensions.

if the mesh is created with a stl in sHM you can scale down the stl with:

surfaceTransformPoints input.stl output.stl -scale '(0.1 0.1 0.1)'

where the three 0.1 's indicate the scaling in x y and z direction

Now if you happen to have a totally different mesh
use transformPoints in a similar way as surfaceTransformPoints.

for more detailed information on these commands type
e.g. transformPoint -help
or see the user guide in the utilities chapter where there
are further hints on other mesh manipulation utilities.

this should solve your problems with the mesh units

regards

[LM4112]

I used ICEM to build the mesh. The problem is that I have different meshes up to 30 million size full hexa and it would be very time demanding to scale all of them. I guess it's easier to use mm.

best regards
Luca

[colinB]

I don't get the problem.
If you convert the mesh to OF
and use transformPoints command the issue should be solved
within minutes even with 30 mio cells.
It is a fully automated process and gives completely satisfying results.

regards

[LM4112]

sorry Colin I didn't read you reply properly. I will definitely try to use transformPoints. I'll let you know if it works properly, thanks

best regards

[LM4112]

Thanks a lot Colin, it worked perfectly.

best regards
Luca

[pardoa]

Originally Posted by Lieven

Yep, that's how I see it.

But just to give you my opinion, if there is no reason except for 'convenience' to deviate from SI units, I would not do it. The chance you make errors with it are relatively big (especially with respect to post-processing).

Cheers,

Lieven

Hello Lieven,

I wish to ask for your help to clarify something regarding the units used by OpenFOAM.

I aim to run interFoam in transient mode over a time period of two months. My input data is in hours, so I would like to set the model time unit in hours. I have already modified the physical constants according to the new time unit in the etc/controlDict. Additionally, I also changed the basic time unit to hours and all the derived and non-symbolic units that depend on the time. The model runs without prompting any error. Now I only need to run the model for several time steps and compare the obtained results for seconds and hours over the same time length. If both results are the same after the corresponding conversion, that would mean that everything is working properly.

However, in my opinion, the model would even run for the new time setup by only scaling the physical constants to hours. The defined time unit in the DimensionSets sub-dictionary doesn't imply anything in terms of modelling. It only sets the position of time [T] in the dimensionSet vector. Changing the name of the time unit from seconds to hours simply helps to understand the model outputs. What really matters is to assign appropriate values for the physical constants according to the new set of units and consistently use the chosen units for all the input data, since the model only cares about the numbers, no matter their "units", right?

Therefore, one time step may be in second or in hours. For the model, any of them will mean a step where to look for convergence. Let's say, for example, that I set my simulation endTime to 20 and my deltaT is 1. If my time unit is seconds, I will be running 20s, whereas if it's hours, in the same period of time the model will run 20 hours. That's right, isn't it?

Based on the previous, if I aim to obtain results every hour over two months, my time control parameters are very strict and can't be increased much (as it happens to surface-tracking problems, Co≈0.5) and additionally my input data is also in hours, it makes sense to change the default time unit to hours. The model will run much faster than keeping the time unit in seconds, convert the input data and obtain a result every 3600 seconds. I would avoid 3600 time steps between each output time if the deltaT is also 1.

I would really appreciate if you could provide me some guidance on this. Thanks in advance for the help!

Álvaro

[Carlo_P]

Hey,

for the second part, try to play around


deltaT 1;

writeControl timeStep;

writeInterval 1;


In your case, you have to assign a very small deltaT (0.01 h) and use 3600*0.01 for writeInterval.


I think that this should work correctly

[pardoa]

Originally Posted by Carlo_P

Hey,

for the second part, try to play around


deltaT 1;

writeControl timeStep;

writeInterval 1;


In your case, you have to assign a very small deltaT (0.01 h) and use 3600*0.01 for writeInterval.


I think that this should work correctly

Hi Carlo,

Thanks for the answer .

So, basically, you recommend me to stick with the default time unit (seconds) and define smaller time steps. That could be another possibility to speed up the simulation. However, my input data is in hours or days (flow rate), so I would rather change the units of the model. I just wanted to make sure that my reasoning was correct. What do you think?

Álvaro

[Carlo_P]

Yes, the easiest way is to maintain the unit in second and change the time when the results are saved.

Sorry that I did a mistake, writeInterval shoud be 3600/timeStep and not 3600*timeStep.

If you need, why you can't change the input data in seconds?

[pardoa]

Originally Posted by Carlo_P

Yes, the easiest way is to maintain the unit in second and change the time when the results are saved.

Sorry that I did a mistake, writeInterval shoud be 3600/timeStep and not 3600*timeStep.

If you need, why you can't change the input data in seconds?

Hi Carlo,

3600/0.01=360000 time steps, which is way more than the initial 3600 time steps for deltaT=1s. I guess you meant to say deltaT=0.01s and EndTime=36s. That would lead again to 3600 time steps. I won't speed up the simulation doing so. Besides, I wish to use adaptive timestepping according to max Courant number.

Álvaro