[joshmccraney]

Hi everyone

A boundary condition in the /U directory looks like this:

    outlet
    {
        type            fixedValue;
	value		uniform (0 VALUE 0);	//fixed inlet velocity
    }

where 6 different numbers are stored in a .dat file for VALUE. Every 5 seconds I would like to change VALUE from the first listed number to the second, and so forth, until all numbers in VALUE are ran.

I thought the easiest way to implement this is a shell script, something like this:

#!/bin/sh
setFields
decomposePar
mpirun -np 16 interFoam -parallel

but obviously more must be added. I'm thinking if I set the controlDict startFrom parameter to latestTime, I could essentially just run the simulation over again (I'm running in parallel, but this doesn't matter, right?), though two parameters must be changed from the shell:


1) in controlDict the endtime needs to be 5 seconds larger than it previously was

2) VALUE in the /U directory needs to grab the next number from the .dat file.

Any help is so appreciated!

[Flowkersma]

Hi Josh,

You could just run one simulation with a time varying boundary condition. See:

  outlet
  {
      type         uniformFixedValue;
      uniformValue    table
      (
           (0   (0 1 0))
           (5   (0 2 0))
           (10 (0 3 0))
           (15 (0 4 0))
           (20 (0 5 0))
           (25 (0 6 0))
      );
  }

Best, Mikko

[joshmccraney]

Originally Posted by Flowkersma

Hi Josh,

You could just run one simulation with a time varying boundary condition. See:

  outlet
  {
      type         uniformFixedValue;
      uniformValue    table
      (
           (0   (0 1 0))
           (5   (0 2 0))
           (10 (0 3 0))
           (15 (0 4 0))
           (20 (0 5 0))
           (25 (0 6 0))
      );
  }

Best, Mikko

Thanks, this looks great and simple! It does look like this approach takes a little more time; do you know how to implement the other approach? Either way, I really appreciate your help!

[Flowkersma]

What do you mean by it takes more time? If you mean in terms of CPU time, it is insignificant. On the other hand if you use the other approach which you suggested, it that takes much more CPU time because of the re-initialization of each simulation.

But if you really want to go for it. It is also quite easy to implement. A bash script with a for loop which loops through the 6 different values and at each iterations does the following:
1. Sets the the boundary condition in 0/U file with sed tool
2. Sets the end time of the simulation in controlDict to 5 units further (sed)
3. Executes the solver
4. Waits for the solver to finish
And as you already suggested, you should set in controlDict the simulation to start from the latest time.

[joshmccraney]

Originally Posted by Flowkersma

What do you mean by it takes more time? If you mean in terms of CPU time, it is insignificant. On the other hand if you use the other approach which you suggested, it that takes much more CPU time because of the re-initialization of each simulation.

So I ran two cases: the first was using the technique you described

  outlet
  {
      type		uniformFixedValue;
      uniformValue	table
      (
           (0 	  (0  1E-1 0))
           (0.05  (0 -1E-1 0))
      );
  }

and the second was running fixedValue, setting controlDict to run from time 0 to 0.05 at a velocity 1E-1 and then going into controlDict, running from last time step to 0.1 s at velocity -1E-1. The table technique took 66s, where rerunning from last time step took 58.44 seconds. So a little over 10% faster.

Originally Posted by Flowkersma

But if you really want to go for it. It is also quite easy to implement. A bash script with a for loop which loops through the 6 different values and at each iterations does the following:
1. Sets the the boundary condition in 0/U file with sed tool
2. Sets the end time of the simulation in controlDict to 5 units further (sed)
3. Executes the solver
4. Waits for the solver to finish
And as you already suggested, you should set in controlDict the simulation to start from the latest time.

Okay, thanks so much for this! So the VEL.dat file stores all values of velocity, and this is in a different directory. Also, there is a VEL_t.dat, which is the timestep duration for each VEL component.

#!/bin/sh

rm -r postProcessing
rm -r processor*
rm 0/alpha.water
rm constant/dynamicMeshDict
cp -r ../mesh/constant/polyMesh constant
setFields
decomposePar

#	LOOP THROUGH ALL OF VEL
for (( i = 0; i < LENGTH($VEL); i++ ));
    
    do

    #	SET LINE NUMBERS
    lineU        = 33
    lineContDict = 26

    #	REPLACE lineU (line 33) in 0/U WITH value uniform (0 $VEL(i) 0)
    sed -i "${lineU}s/.*/value uniform (0 $VEL(i) 0);/" ./0/U

    #	UPDATE endTime (line 26) IN system/controlDict WITH VEL_T
    sed -i "${lineContDict}s/.*/endTime i*$VEL_t;/" ./system/controlDict

    #	RUN SOLVER
    mpirun -np 16 interFoam -parallel # > log.interFoam & # COMMENT TO VIEW OUTPUT

done

Obviously there are a few pieces here that don't work. I'll list what I think is wrong, and if you can help I'd be very happy:

1) unsure how to grab the length of the VEL vector, so I wrote LENGTH($VEL)
2) how to grab the component values of the VEL vector, so I just wrote $VEL(i)
3) how to let the system know where VEL is even stored so it can grab values from there

If you see anything else I'd really appreciate it! This was tough for me!

[Flowkersma]

Surely the faster technique depends on many factors such as how long the initialization time is in comparison to the total simulation time. I'm still surprised that the time dependent boundary condition is so expensive.

I'm not the right person to ask about Bash programming. For more complicated things I use Python but what you want to should be still doable:

1. length of vector: ${#vector[@]}

2. component i of vector: ${vector[i]}

3. better do an online search

[joshmccraney]

Originally Posted by Flowkersma

Surely the faster technique depends on many factors such as how long the initialization time is in comparison to the total simulation time. I'm still surprised that the time dependent boundary condition is so expensive.

I'm not the right person to ask about Bash programming. For more complicated things I use Python but what you want to should be still doable:

1. length of vector: ${#vector[@]}

2. component i of vector: ${vector[i]}

3. better do an online search

Thanks a ton! Online search remains ongoing. lol

[joshmccraney]

Hey Flowkersma

One last question. Would you execute these changes from a shell script or in python? More importantly, why?

[Flowkersma]

I would still do this in a Bash script but for anything more complex I would use Python. I know Python much better and I think it's better general purpose language. Some commands (e.g. copy/remove file, change directory) are simpler in Bash because it is the command line language. Also, it has some very powerful commands such as sed.

In a Python script you can also execute Bash commands or the other way around so you can combine the best of both worlds. Here are a couple of examples with Python's subprocess module to call Bash:

subprocess.call(['simpleFoam','-case','firstCase'])
subprocess.call(['sed','-i', 's/endTime 1;/endTime 5;/','system/controlDict']

[joshmccraney]

Hey Mikko

It appears the table you suggested gives drastically different results than running the simulation for a set amount of time, then switching the controlDict and U files to the next spot in the time step, and so on. Any idea what is happening?

What makes maters even worse, when I use a python script I wrote that copies the values for U from a different file (same file I manually copy from) I get different results still! The odd thing is I can look at the U file and ensure it matches the manual copy.

Please advise!

[Flowkersma]

Hi Josh,

Have you compared the boundary condition values at the same time steps between the different approaches? If you read the documentation of 5.2.3.4 Time-varying boundary conditions, the table boundary condition interpolates values linearly between times. I guess you can overcome this by defining the table as follows:

  outlet
  {
      type         uniformFixedValue;
      uniformValue    table
      (
           (0   (0 1 0))
           (4.9999   (0 1 0))
           (5   (0 2 0))
           (9.9999   (0 2 0))
           (10 (0 3 0))
           (14.9999   (0 3 0))
           (15 (0 4 0))
           (14.9999 (0 4 0))
      );
  }

Now the boundary condition will be exactly one between times from 0-4.9999 and at time step 5 it will switch to 2. If you have a time step which is between 4.9999 and 5 then the value will get interpolated in between so choose a value which is closer to 5 than 5-deltaT.

[joshmccraney]

Originally Posted by Flowkersma

Hi Josh,

Have you compared the boundary condition values at the same time steps between the different approaches? If you read the documentation of 5.2.3.4 Time-varying boundary conditions, the table boundary condition interpolates values linearly between times. I guess you can overcome this by defining the table as follows:

  outlet
  {
      type         uniformFixedValue;
      uniformValue    table
      (
           (0   (0 1 0))
           (4.9999   (0 1 0))
           (5   (0 2 0))
           (9.9999   (0 2 0))
           (10 (0 3 0))
           (14.9999   (0 3 0))
           (15 (0 4 0))
           (14.9999 (0 4 0))
      );
  }

Now the boundary condition will be exactly one between times from 0-4.9999 and at time step 5 it will switch to 2. If you have a time step which is between 4.9999 and 5 then the value will get interpolated in between so choose a value which is closer to 5 than 5-deltaT.

Makes perfect sense: thank you so much! I missed this piece of info, I'll read more carefully next time.

I do have a question for you: when running through the table manually, so using the approach below rather than table:

    outlet
    {
	type            fixedValue;
        value           uniform (0 -2.3074827e-04 0); 
    }

if I set the controlDict to end at time 5 at a specified velocity, then go into the U file and edit the outlet value to something different, how do I tell interFoam to acknowledge this? Because if I simply execute mpirun -np 16 interFoam -parallel the code doesn't seem to understand that the U BC has changed.

Do you know what I'm missing? Either way, the table works, so thank you!

[Flowkersma]

The boundary condition is read from the time-step that you specify in controlDict so you have to change it in that folder. So if you stop your first simulation at t=1 and start it again from latestTime, then you should modify the boundary condition in 1/U file.