If it is easy, then something is fishy!
The momentum predictor on my fvSolution file was already on. Seems that's not the problem here. Please have a look at my case file and see if you could spot something wrong.
The log file for subsetMesh have an error! (I tested with OF6.0).
You need to fix the problem in the meshing first.
I am woundering how the simulation runs by you.
You are simulating transient. Is that right?
Thanks for checking up on my case. Sorry it was my bad! I have fixed the case to have only 2 regions now. 77 regions were created because subsetMesh failed due to not removing some old cellToRegion files using my AllClean script. Also, i'm actually using a maxCo of 1. I've been trying different settings to see the cause of the problems, that's why it was at 1000, but i've changed it back. Please have a look at let me know your thoughts.
I can't open the zip on my phone so I'll just guess, you don't have frozenFlow on do you?
If that's not it, go have a look at the source for chtMultiRegionFoam and find any "if" statements or other conditionals that might cause a skip of the U solution.
I rebulit the mesh you have in your case using salome and used the setups you have in your case.
Your mesh has different problems, as checkMesh has told me.
All The boundary condithins, themophysical proberties... has been imported from your case.
I just changed the mesh and the velocity at the outlet from zeroGradient to inletOutlet.
That means that your setups are working.
If you look to the log file of snappy, you will notice that the maximum number of cells need to be increased in snappy from 200000 to a higher value!
That need to be done, but does not solve the problem!
I have no idea what you want to do with those two.
Anyway you are isolating the sourrounding boundaries and take them out of the simulation. And that includes the inlet and the outlet.
Would you please descibe the target of using those two utalities. ie what you want to do?
Anyway, here is the case meshed with salome.
Do you want to simulate transient or steady state?
PS: The gravity should be in Z direction!
I basically learnt that method from an old post by wyldckat for removing the background mesh. Here is the link Background Mesh in snappy with multi domain (CHT).
From my understanding (maybe i'm wrong), the background mesh is not totally removed after using blockMesh. I experienced this and that was the reason it created 77 regions as you pointed out previously.
So, it would seem from the post, setSet was used to create a cellZone isolation which includes the needed zone (air and copper) and the subSetMesh command is used to tell OpenFOAM to create a new mesh from the 'isolation' and overwrite existing mesh. This has been my philosophy for the past couple of weeks i started learning chtMultiRegion.
I would agree with you this makes sense. However, this was my only way of not coming up with multiple unneeded regions; sometimes running into hundreds. If you have any way of avoiding this without subsetting the mesh please let me know. My objective is to run the whole simulation, including making the mesh using snappy in OpenFOAM. Based on what you pointed out, one possible solution which i've not tried but i think might work is creating the patches after snappyHexMesh and subsetMesh using topoSet and createPatch. Maybe then, the interior domain can absorb the boundary condition instead of it being isolated.
Thanks a lot for this and the included python script. Your simulation meshing with Salome indeed runs. This problem i'm simulating is meant to be a simplification of a much complex problem i plan to run i future. I thought it would be easier to mesh using snappy, but i'm beginning to reconsider. Would you have a recommended method of multiregion meshing using snappyHex? Also, i'm trying to open the Salome study file to see your meshing process, but for some weird reason, the file opens but nothing shows up. I've tried on salome 7 and 8.
Are you want to simulate transient or steady state?
I'm trying to simulate transient, but the simulation timestep is painfully slow using a maxCo of 1. I wonder how that could be increased without using much larger cells. Anyway, it is my understanding that chtMultiRegion doubles as as both a steady state and transient solver. To change to steady, i just need to switch the ddtScheme to 'steadyState' and change PIMPLE to SIMPLE in fvSolution? Please correct me if i'm wrong.
I actually meant to simulate a horizontal pipe with fluid flowing in the z direction, and i think the gravity is pointed correctly in the y direction.
Once again, thanks for your great work Peter!
The transient simulatiuon is running very slow. You are right!
The reason for this is the very high density of the solid region (copper) in your case!
rho =8000 means that the solid will take too much time to increase its temperature because the momentum is very high.
By the way, if the transient part of the simulation is not necessery, then the "transient" simulation calculation time could be increased by reducing the density of the solid to 1!
After the convergence happends you can increase the density one more time to get the final results.
Like that you dont need to change the ddt sheme and fvSchemes and fvSolution!
The problem with your mesh is that you have a very coarse stl mesh. (I am not sure here).
Snappy setups need to be tuned to get a good mesh.
After snappy and before making the next steps, just run checkMesh. You will notice that the mesh quality is bad and checkMesh failed.
That why I made the mesh with salome, caus I like it more.
Finished meshing with 76 illegal faces (concave, zero area or negative cell pyramid volume)!
I am working now on the case using snappy.
Nice trick I should try that out when i'm switching to steady state.
Yeah i know this. But the purpose was to practice for a much bigger simulation that couldn't be simplified using blockMesh and topoSet.
The problem was in the stl files you use.
I just replaced yours with others that I generated myself.
I did not change anything else.
I never knew that would be an issue as far as both surfaces are closed. I particularly checked using surfaceCheck to be sure. Please tell me how you generated the stl that might be different from what i did previously?
Well, I used Salome before to generate the mesh.
From the geometry that I generated there based on your geometry I generated the STL files.
By the way, the quality of my STLs is lower than yours!
If you compare the size of my files with yours, then you will see that my files are smaller.
You could increase the maxDi from 10 to about 20.
That will let the simulation run faster.
That's the funny thing. I actually used Salome that's why i'm wondering where i went wrong. I created my geometry in solidworks, exported the STEP file to Salome and generated the STLs from the software to ensure they were water tight.
I thought a higher size STL means better quality? It's confusing how a lower quality should work and a higher one fails. Is there any possible reasoning behind that? Also are you generating the STL's from the mesh or geometry module? I need to be clear. If from the mesh module, what rule of thumb do you use for the meshing? same size?
I descovered that by sudden, as I exported the STL from salome with very high quality.
The result was that I got more stand alone zones using spliteMesh.
Anyway, I increased before the mesh quality in snappy in the lines: 138 and 148. And the stand alone zones increased. I reduced the quality and I got less stand alone zones.
That was the key to look for STL quality and to generate them myself.
The STLs has been generated from the geometry.
The STLs has been generated from the geometry. Mesh do not export STLs!
Please tell me. How do you adjust the quality of the stl from geometry module during export?
Peter was able to get the simulation running and solving for the velocities. Surprisingly, the issue was with my stl file according to him. I didn't think that would be an issue because I did a surfaceCheck and they were all closed. I created the STLs in Salome and imported into OpenFoam. At first, after splitMesh I had over 100 regions, then I used the method of subsetMesh which you talked about in an old post to reduce to the 2 required regions. The simulation ran but without calculating the velocities and I couldn't figure out why.
Peter had to recreate my geometry in Salome, but ran into the same problem using the same high resolution stl like I did. But it's surprising that when he eventually reduced the quality of the stl, he obtained only 2 regions without using the setSet or subsetMesh. I would think that the higher the resolution of the stl the better, so it's counter intuitive and I wonder why.
Could you please tell me your process of doing cht multiregion simulations for complex geometries from the stage of geometry creation to stl generation, meshing and splitting mesh. I've seen different people with different methods and it's a bit confusing. I need to know a standard method that works for most cases and stick to it for future simulations. The tutorials though informative, does not take into account complex geometries.
I rarely do simulations with "chtMultiRegion*Foam" solvers myself, so I'm not familiar with issues with STLs and potential problems with the meshing process.
I don't use Salome myself but have guided one or two people in how to use it for multi-region cases.
Now, based on the information on this thread and Obi's PM, my guess is that the problem is that there are doubled surfaces. For example, if you have a box inside another box, you should not have 2 STL surfaces for each side of the internal box: if you have the internal box surface present inside the outer box, then the mesher will get confused with "which side is which for what exactly?"
So my guess is that when the STLs were made coarser, all of the vertices were perfectly coincident without any doubts on how both sides of the inner box (in my hypothesis) would match.
So, what if the hypothetical boxes are side by side? Technically, you should ensure that the same exact solid block for the shared surface is used in both within each STL files, so that the solid entry has the exact vertex definitions, without any mildly different digits. Not exactly a practical solution, if you exported the STL files from elsewhere, I know... but from my experience, that's how you ensure snappyHexMesh behaves properly for multi-region meshes.
As for the extra regions: I haven't looked into the STL files myself, so my guess is that there is an ambiguous surface overlap where the additional regions appeared. For example, if two contiguous boxes were meant to have a matching vertex that is shared by both, but ended up not matching and having the two vertexes end up inside the other box.
I hope this at least somewhat helps... if it's necessary, I can try and look into the case and STL files myself, to try and give a better diagnosis on what happened.