Time units OpenFOAM

pardoa · August 15, 2019, 19:26

Hello everyone,

I have a very simple question to ask you all: the time units on OpenFOAM must be always in seconds? The OF User Guide states that the model can be used for any system of units, however I don't know if those units have to be always the base ones, as specified in the Guide for the IS and the USCS.

I would like to define the time control parameters in days or hours, so I need to know if it's indeed possible to do so rather than having to do it in seconds.

Thank you so much in advance!

Álvaro

Adam_K · August 16, 2019, 02:24

You can use whatever you want for the units. The input data just needs to be correct for the chosen set of units. Keep in mind that OpenFOAM uses some dimensioned physical constants in some cases.

Gerry Kan · August 16, 2019, 03:47

Hi Álvaro:

Yes, OpenFOAM uses "dimensioned" scalars and vectors but these are restricted to basic SI units, i.e., kg, m, s, K, mol, A, and Cd (candela). I don't think you can change that.

I imagine you are interested in displaying these units in hours and days. The no-code solution is conversion, but if you want a more user friendly solution, I am afraid you will have to create your own solver for that.

Another issue concerns the postprocessed results. So far they will be sorted by the time elapsed in seconds. I don't know how much work it is to convert them to the time units you desire. Maybe (in Linux) a link (ln -s) from the original folders (in seconds) to new names (in hours / days), for which you can write a script to automate, would suffice?

Hope that helps, Gerry.

pardoa · August 16, 2019, 13:55

Hello!

Thanks for the answers and help

.

As far as I understand, the units that are used in the model are preset to the base/basic units of the International System (IS). Nevertheless, any other system of units should be object of application on OpenFOAM after modifying the chosen set of units and dimensioned physical constant values in the DimensionSets and DimensionedConstants subdictionaries of the main controlDict file of the OpenFOAM installation ($WM_PROJECT_DIR/etc/controlDict).

Therefore, since I aim to define all my time control parameters in days or hours, I should modify the scalar value of the basic unit "s" (seconds) to 3600 if my input data is in hours and to 86400 if it's in days. Likewise, all constants whose dimension set includes a temporal unit should be changed accordingly.

Does this approach sound reasonable for you? Thanks!

Álvaro

pardoa · August 19, 2019, 06:20

Quote:

Originally Posted by pardoa

Hello!

Thanks for the answers and help

.

As far as I understand, the units that are used in the model are preset to the base/basic units of the International System (IS). Nevertheless, any other system of units should be object of application on OpenFOAM after modifying the chosen set of units and dimensioned physical constant values in the DimensionSets and DimensionedConstants subdictionaries of the main controlDict file of the OpenFOAM installation ($WM_PROJECT_DIR/etc/controlDict).

Therefore, since I aim to define all my time control parameters in days or hours, I should modify the scalar value of the basic unit "s" (seconds) to 3600 if my input data is in hours and to 86400 if it's in days. Likewise, all constants whose dimension set includes a temporal unit should be changed accordingly.

Does this approach sound reasonable for you? Thanks!

Álvaro

Any comment on this? Thanks!

Adam_K · August 19, 2019, 07:30

Quote:

Originally Posted by pardoa

Hello!

Thanks for the answers and help

.

As far as I understand, the units that are used in the model are preset to the base/basic units of the International System (IS). Nevertheless, any other system of units should be object of application on OpenFOAM after modifying the chosen set of units and dimensioned physical constant values in the DimensionSets and DimensionedConstants subdictionaries of the main controlDict file of the OpenFOAM installation ($WM_PROJECT_DIR/etc/controlDict).

Therefore, since I aim to define all my time control parameters in days or hours, I should modify the scalar value of the basic unit "s" (seconds) to 3600 if my input data is in hours and to 86400 if it's in days. Likewise, all constants whose dimension set includes a temporal unit should be changed accordingly.

Does this approach sound reasonable for you? Thanks!

Álvaro

Personally, I'd just stick with the standard units and have sampling time every 3600 s or whatever it is. I think that is easier to keep track of than having to update all your constants to be in non-standard units.

pardoa · August 19, 2019, 08:50

Quote:

Originally Posted by Adam_K

Personally, I'd just stick with the standard units and have sampling time every 3600 s or whatever it is. I think that is easier to keep track of than having to update all your constants to be in non-standard units.

Yes, probably it's better to stick with the default standard units rather than modifying them. Thanks for the comment!

Gerry Kan · August 22, 2019, 04:43

Hi Álvaro:

Sorry for the delay. I didn't know that you already posted a reply days ago.

Yes, I would say if there is not particular reason that other time units must be used, then I would recommend sticking with seconds.

Trying to keep track of time in addition to this is not a too trivial task and I would only recommend this if you have time, or when it is absolutely necessary.

Gerry.

pardoa · August 22, 2019, 06:00

Quote:

Originally Posted by Gerry Kan

Hi Álvaro:

Sorry for the delay. I didn't know that you already posted a reply days ago.

Yes, I would say if there is not particular reason that other time units must be used, then I would recommend sticking with seconds.

Trying to keep track of time in addition to this is not a too trivial task and I would only recommend this if you have time, or when it is absolutely necessary.

Gerry.

Hi Gerry,

No worries. Thanks for the answer!

After posting my comment, I was thinking about it and realized that what I said about changing the scalar value of the basic time unit (seconds) might be wrong. I would only scale the dimensioned physical constants according to the new time unit. Also, if desired, one could also switch the name of the basic time unit from seconds to the new unit in the DimensionSets sub-dictionary as well as all the derived and non-symbolic units that depend on the time. Changing the name of the time unit shouldn't imply anything in terms of modelling, since the model only cares about the numbers (scalar physical constants), no matter their "units".

I did both things for a time unit of hours and the model run without halting execution. Now I only need to run it 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. I'll let you know.

You can find a more detailed description of my reasoning here (post #11): units OpenFOAM. What do you think?

Álvaro

Gerry Kan · August 23, 2019, 04:21

Hi Álvaro:

I have a read over the link. It seems that your original idea of having the time unit converted from "seconds" to "hours" is because your input data are in hours, is that correct? In that case I also agree with Carlo. Converting the timestamp for these input data back to seconds is the most effective way to go.

The other aspect of this, based on reading this thread, is that you are worried that the time step might be too small when it is in seconds? I am not sure if my understanding is correct.

Of course, you want as small a time step your computer / patience can afford, but more importantly on the complexity of your flow geometry and physics. The Courant number display at the end of each iteration should tell you whether your time step is too big or too small.

If you are really concerned with the runtime, I would suggest, as first measure, running this case on a much coarsened mesh, and increase the time step accordingly. From this you should get an idea what to expect and select your mesh refinement strategy more effectively, so that you can still achieve reasonably accurate solutions quick enough.

I hope that helps, Gerry.

August 15, 2019, 19:26	Time units OpenFOAM	#1
pardoa New Member pardoa Join Date: May 2018 Posts: 29 Rep Power: 8	Hello everyone, I have a very simple question to ask you all: the time units on OpenFOAM must be always in seconds? The OF User Guide states that the model can be used for any system of units, however I don't know if those units have to be always the base ones, as specified in the Guide for the IS and the USCS. I would like to define the time control parameters in days or hours, so I need to know if it's indeed possible to do so rather than having to do it in seconds. Thank you so much in advance! Álvaro Last edited by pardoa; August 16, 2019 at 12:20.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
High Courant Number @ icoFoam	Artex85	OpenFOAM Running, Solving & CFD	11	February 16, 2017 14:40
OpenFOAM v3.0+ ??	SBusch	OpenFOAM	22	December 26, 2016 15:24
Star cd es-ice solver error	ernarasimman	STAR-CD	2	September 12, 2014 01:01
Micro Scale Pore, icoFoam	gooya_kabir	OpenFOAM Running, Solving & CFD	2	November 2, 2013 14:58
Could anybody help me see this error and give help	liugx212	OpenFOAM Running, Solving & CFD	3	January 4, 2006 19:07

August 16, 2019, 02:24		#2
Adam_K Member Adam Join Date: Nov 2018 Posts: 36 Rep Power: 8	You can use whatever you want for the units. The input data just needs to be correct for the chosen set of units. Keep in mind that OpenFOAM uses some dimensioned physical constants in some cases.

August 16, 2019, 03:47		#3
Gerry Kan Senior Member Gerry Kan Join Date: May 2016 Posts: 376 Rep Power: 11	Hi Álvaro: Yes, OpenFOAM uses "dimensioned" scalars and vectors but these are restricted to basic SI units, i.e., kg, m, s, K, mol, A, and Cd (candela). I don't think you can change that. I imagine you are interested in displaying these units in hours and days. The no-code solution is conversion, but if you want a more user friendly solution, I am afraid you will have to create your own solver for that. Another issue concerns the postprocessed results. So far they will be sorted by the time elapsed in seconds. I don't know how much work it is to convert them to the time units you desire. Maybe (in Linux) a link (ln -s) from the original folders (in seconds) to new names (in hours / days), for which you can write a script to automate, would suffice? Hope that helps, Gerry.

August 16, 2019, 13:55		#4
pardoa New Member pardoa Join Date: May 2018 Posts: 29 Rep Power: 8	Hello! Thanks for the answers and help . As far as I understand, the units that are used in the model are preset to the base/basic units of the International System (IS). Nevertheless, any other system of units should be object of application on OpenFOAM after modifying the chosen set of units and dimensioned physical constant values in the DimensionSets and DimensionedConstants subdictionaries of the main controlDict file of the OpenFOAM installation ($WM_PROJECT_DIR/etc/controlDict). Therefore, since I aim to define all my time control parameters in days or hours, I should modify the scalar value of the basic unit "s" (seconds) to 3600 if my input data is in hours and to 86400 if it's in days. Likewise, all constants whose dimension set includes a temporal unit should be changed accordingly. Does this approach sound reasonable for you? Thanks! Álvaro

August 22, 2019, 04:43		#8
Gerry Kan Senior Member Gerry Kan Join Date: May 2016 Posts: 376 Rep Power: 11	Hi Álvaro: Sorry for the delay. I didn't know that you already posted a reply days ago. Yes, I would say if there is not particular reason that other time units must be used, then I would recommend sticking with seconds. Trying to keep track of time in addition to this is not a too trivial task and I would only recommend this if you have time, or when it is absolutely necessary. Gerry.

August 23, 2019, 04:21		#10
Gerry Kan Senior Member Gerry Kan Join Date: May 2016 Posts: 376 Rep Power: 11	Hi Álvaro: I have a read over the link. It seems that your original idea of having the time unit converted from "seconds" to "hours" is because your input data are in hours, is that correct? In that case I also agree with Carlo. Converting the timestamp for these input data back to seconds is the most effective way to go. The other aspect of this, based on reading this thread, is that you are worried that the time step might be too small when it is in seconds? I am not sure if my understanding is correct. Of course, you want as small a time step your computer / patience can afford, but more importantly on the complexity of your flow geometry and physics. The Courant number display at the end of each iteration should tell you whether your time step is too big or too small. If you are really concerned with the runtime, I would suggest, as first measure, running this case on a much coarsened mesh, and increase the time step accordingly. From this you should get an idea what to expect and select your mesh refinement strategy more effectively, so that you can still achieve reasonably accurate solutions quick enough. I hope that helps, Gerry.