Hi Kumudu,

If you study this guide: http://linuxcommand.org/learning_the_shell.php - you should be able to figure it out on your own ;)

But the answer is simple:

1. "refineMeshByCellSet()" is a shell function.
2. "refineMeshByCellSet 1 2 3" means that "1 2 3" are the arguments sent to the function.
3. "$1" refers to the first argument that the function receives.
4. "shift" means that the list of arguments is shifted to the left, therefore changing "1 2 3" to "2 3" and later to "3" and then to "". How? Thanks to the "while", which is a loop.
5. Basically this means that there are 3 files:
   
   Code:

   ---

   system/topoSetDict.1
system/topoSetDict.2
system/topoSetDict.3

   ---

   that are copied to "system/topoSetDict" (one at a time) and then refineMesh is executed with this dictionary file (one at a time).

Best regards,
Bruno

Dear Bruno,

Thank you very much.

Best regards,
Kumudu

Dear Bruno,

I am back again after long time finishing all the exams.

I have followed the steps you mentioned in the above. I still have maxZ face at the inlet and outlet faces. I use the "topoSet -dict system/topoSetDict01 -region water" and "createPatch -overwrite -region water" as you said.

I am attaching the files and figures of the top view of the water region that shows maxZ at the inlet and outlet.

Could you please tell me, what would be the reason that I still have these faces?

Thanks in advance.
Best regards,
Kumudu

Dear Bruno,

These are the steps I followed,if in case you need to check them,

P { margin-bottom: 0.08in; } runApplication blockMesh


#define the cell set "refineCells" for the refinement and then refine
runApplication topoSet -dict system/topoSetDictRefine
runApplication refineMesh -overwrite -dict




#define the zones for the regions and split the mesh into regions
runApplication topoSet -dict system/topoSetDictRegions
runApplication splitMeshRegions -cellZones -overwrite


#define the faceSets for the inlet and outlet patches and create the patches
runApplication topoSet -dict system/topoSetDictFaceSet -region water
runApplication createPatch -overwrite -region water



Please find the attached files. I couldn't attach them as a one Zip file. So, I am attaching them as 0,constant and system.

Thanks in advance.
Best regards,
Kumudu

Hi Kumudu,

You have the boxes defined too tightly. Basically, if a box has a lower Z of 40 and a higher Z of 40, nothing can fit inside, because it's a plane and not a box :)
Keep in mind that it's a "boxToFace", not a "planeToFace" (I don't think this one exists) ;)

Edit the file "system/water/topoSetDictFaceSet" and notice the changes I've made:
The idea is for "zmaxP1a" and "zmaxP1b" to be close enough to the faces you want to catch, but without exceeding the numerical limits. For example, these values are bad:
The first pair is wrong because it's beyond the computational number resolution; the second pair is wrong because it passes beyond the centre of the cell associated to the patches.

Best regards,
Bruno

Dear Bruno,

Thank you very much. Now I understand what was wrong. I will make the corrections and let you know.


Best regards,
Kumudu

Dear Bruno,

It worked. Thank you very much.

Best regards,
Kumudu

error occured in chtMultiRegionFoam
 

Dear Bruno,

I have created a case which have four different materials (water,pipe,filling material, soil). I use blockMesh to create the domain and then use the topoSet to define the regions. This time I defined the inlet and outlet for the fluid region using the blockMeshDict.

I have used several blocks with different grading in the mesh to catch the different length scales in my problem. I have attached the .jpg file of the regions. But when I run the file for 10s, it just run for 5s and gave the error massage:
--> FOAM FATAL ERROR:
[1] Maximum number of iterations exceeded


I have then changed the line
"const int Foam::specieThermo<Thermo>::maxIter_ = 100;"

in the
opt/openfoam211/src/thermophysicalModels/specie/lnInclude$ gedit specieThermo.C

into

"const int Foam::specieThermo<Thermo>::maxIter_ = 5000;"

But, it still gives me the same error. I have attached the case file. Could you please tell me how to fix this problem. Is this problem cause due to my mesh?

Thanks in advance.

Best regards,
Kumudu

error occured in chtMultiRegionFoam
 

Dear Bruno,

here is part of the full error message:

best regards,
Kumudu

Hi Kumudu,

So, this is basically several problems in a single case.

Firstly, you're using chtMultiRegionFoam, which is a transient solver and which requires for the Courant number to stick to low values, usually around 0.5 at most. Since you turned off automatic deltaT adjustments:
the solver's only choice was to blow up the simulation, because it was impossible to solve the problem :(
More specifically, this is what I'm talking about, which is the time iteration prior to the one that crashes:
Shown in bold are several critical issues, where the last one is the Courant Number values for the water region. I would say that "2.799531e+08" is waaaaaaaaaaaaaaaaaay bigger than 0.5 ;)


The actual reason for this? Run this command, after the mesh is completely done:
Among the lengthy output, this is shown:
The smallest volume is "5.3733903e-09" m³! That is a reaaaaally small volume :)
Remember the very first tutorial in the OpenFOAM User Guide: http://www.openfoam.org/docs/user/cavity.php :confused:
It explains there how the Courant Number is calculated... which is directly related to the volume of a cell (unless you're simulating in 2D).


And what cells is this in reference to? Here's the problem:
Attachment 29035
Click on the image and you'll see a very thin line of cells in the U part of the pipe. Those are the cells that are causing the problem.


Unfortunately, this is probably not the only problem. You're using really long cells along the pipe, which can lead to problems in the near future. Why? Because meshes are extremely important for quality simulations+results.
Here's a compilation of the interesting cases I've had the pleasure of analysing here on the forum: OpenFOAM: Interesting cases of bad meshes and bad initial conditions - innocent looking meshes resulted in solver crashes or at least lead to non-physical results. There you should be able to see for yourself what bad cell proportions can lead to.


Best regards,
Bruno

Dear Bruno,

Thank you very much. When I set the time step to 0.01 and remove the grading in the Z-direction by catching the U-part of the pipe with another block with dz=0.012, the error didn't appeared. Because,Courant Number was 0.3 at that part.

Thanks again,

Best regards,
Kumudu

changing the boundary conditions with time
 

Dear Bruno,

I want to run the chtMultiRegionFoam with different inlet temperature and velocity magnitudes at different times. For example, lets say I want to change the inlet temperature of the fluid region hourly so that heat load to the system will change hourly. Also, after 12 hours of circulating the water in the pipe, I want to stop the circulation by setting the velocity equal to zero and recirculate it again after another 12 hours . Is there any way that I could set these conditions easily ?


Also, I have another question regarding run the chtMultiRegionFoam in parallel.

My server has 6 processors and I want to decompose the 4 regions (soil,water,...) into these 6 processors and run it.

I changed the decomposeParDict as follows,

And run it as follows,

But I got an error. Could you please tell me how to run it correctly.
Thanks in advance.

Best regards,
Kumudu

Hey guys,

Your discussion is very interesting. In fact, I just ran into a similar problem that I do not know how to solve. I am trying to model a 2D geometry as attached. As you can see I have one dome resting on top of a rectangle surrounded by walls. I am also trying to simulate a conjugate heat transfer problem but my problem is while using the topoSetDict. This is my topoSetDict file so far:

As you can see, I am using the cylinderToCell to tackle the 2D dome and the boxToCell to cover the rectangle below. The problem is that for some strange reason this is not working. When I run topoSet on the command line this is what it prints:

I did some research on this problem - http://www.cfd-online.com/Forums/ope...nal-field.html - and I noticed that my units are correct. Would it be possible for you guys to take a look at this case? Please let me know if you would like me to send the blockMesh file.

I greatly appreciate your attention,

Lucas

Hi Lucas,

I am no expert in this area. But, I think the problem is with defining the topoSet region using cylinderToCell.

"keyword p1 is undefined in dictionary "/home/meisu/OpenFOAM/meisu-2.2.1/run/Research/ConjugateHeatTransfer/RayleighBenard/caseTwoDomeThreeWalls/system/topoSetDict.actions.sourceInfo"

The above error indicates that the problem is with p1. I haven't use the cylinderToCell before. But, have a look at it again.

Best regards,
Kumudu

Hey Kumudu,

Thanks for your response. I believe cylinderToCell might not be the best command so I am currently trying the zoneToCell approach. It turns out that I may execute the topoSetDict but unfortunately new domains are created (i.e. domain4, domain5, etc). I don't quite understand why. It is not a matter of unit for sure. Since I am dealing with half a circle it seems to me that the zoneToCell command is not properly covering all the regions. Also, I cannot identify the location of these domains so it is hard to to say where exactly the problem is. Would you be able to help me out with that?

Thanks a lot,

Lucas

Hi Lucas,

When I first create my regions, I got the same kind of problem. Like making excess domains. It is not due to type of the topoSet dictionary. You can view the excess domain by using paraview. Give the command, paraFoam - touch All. I am not sure. But you can find it in the Allrun file. Then view each domain by loading one by one. Then check your blockMesh dictionary. And change the cell size and run again the topoSet regions. You will find the error eventually.

Best,
Kumudu

Hey Kumudu,

Thanks for the input. Actually what I am trying to do is to break down my dome into a simpler geometry and trying to execute it. it seems that now I no longer have problems with the domains but instead this annoying message pops when I run the code. I have done some research but it is not clear what the problem is. What is the mystery behind this no finite volume options present?

Cheers

Greetings to all!

@Kumudu: Sorry for taking so long to answer you, but I haven't had the time to look into your questions sooner.

Let's see...
Let me think a bit... one way is to run the case for 1h and then change the BC manually or using changeDictionary, then changing "controlDict" for the new time.
But I think the easiest way would be to use a table based boundary condition. There was a couple of discussions on this topic sometime ago here: http://www.cfd-online.com/Forums/ope...lefile-bc.html - and here: http://www.cfd-online.com/Forums/ope...ixedvalue.html

Note: Be careful, because this feature of using data from a table means that it will interpolate between 2 time items on the list: http://www.openfoam.org/version2.1.0...conditions.php
Example:
means that it will linearly interpolate all values from 0 to 10.0, for each respective time instance within the 0 to 100 iterations or seconds! So you'll need something like:
Of course this is possibly an excessive change, so you might want to be careful with abrupt changes between 2 contiguous time snapshots!


:confused: Knowing what error message you've gotten would make it a lot easier to diagnose! My guess is that your script is missing the first few lines that are usually present in the Allrun scripts, namely:
------------------

@Lucas:
It's an information only message, which indicates that there are "No finite volume options present" in the file "system/fvOptions" ;)

When in doubt: run a similar tutorial case from OpenFOAM, to ascertain what's normal and what's not normal ;)

Best regards,
Bruno

Dear Bruno,

Many thanks for replying me. I will look into it carefully.

Best regards,
Kumudu

Porting PlaneWall 2D for OF1606+
 

Hello everyone,

I have been trying to port the classic PlaneWall 2D case for the latest OF release. I am attaching the zip for all files. The case runs well, but in the end it throws a ton of errors on ParaView and results are in my opinion unrealistic.

Can somebody take a look at it and please let me know what all could be the probable causes ?


Thanks!

P.S. I use OF+ on windows, use native ParaView. Once the simulation is finished, you can open foam.foam file in PV for postprocessing.