Hi Nasir,

The problem is that you already have another working version of OpenFOAM installed. You need to edit the file "~/.bashrc" and change the existing line to become also an alias, for example:
Save and close the file.
Then start a new terminal and run:
now you should be ready to continue.

Best regards,
Bruno

Thank you very much for your prompt reply, i figured that out after deleting all the versions lol...

i am going to reinstall it now and give it a shot. will post result later today hopefully :o

Also,

please can you clarify the difference between region-wise-refinement and cell zone in surface refinement. i am still a bit puzzled :confused:

thanks

Hello Bruno,

I did as you said. however, i got this at the end:

i can see an error at end due to some permission denied.

anyhows, i ve decided to run the case as it is:

problem is i don't normally see the simulation or log running on terminal anymore, the screen is just paused on:

but from my system monitor, i can clearly see all the CPUs max out and ram being used, i would also say the ram usage seems to have reduced slightly, i will post the log file later today in the morning (uk time).

thanks allot bruno.

Hi Nasir,

The cellZone definition for each item in "refinementSurfaces" refers to each STL file having to be a closed surface. For example, this:
implies that the "inlet" geometry is a closed shell and that the surface is to be assigned to the faceZone "inlet" and that the meshed cells inside the geometry "inlet" should be assigned to a cellZone named "inlet".
In your case, only the faceZone can be created, because your "inlet" geometry is in fact a single surface with no thickness, not a closed shell.

"refinementRegions" refers to volume regions to be further refined. The surfaces of these regions are not assigned to: patches, faceZones nor cellZones. They are only used as refinement locators.

My guess is that you didn't start a new terminal, because you were still using OpenFOAM 2.4.0 and not 2.4.x. Check the instructions on my previous post again ;)

That's normal. I didn't mention that was normal, because this is a standard convention when using OpenFOAM applications, where the output is logged into a log file while it's running. You can inspect the current progress by opening another terminal in the same folder and checking the contents of the file "log.snappyHexMesh", with either one of these commands:
The first one only shows the last 10 lines of the file and the second one allows reading the content of the file. The cursor keys, "Page Up" and "Page Down" can be used for seeing the content of the file. The key "q" exists the "less" application.

Best regards,
Bruno

Hello Bruno, thanks for your reply. hmmm ok now i get the difference between the two, however, for some reason the internal mesh doesn't get properly refined, i don't know why?

however i am starting to feel it has to do with with the fact that i am using the standard edge refinement without levels instead of the new feature edge refinement feature which allows users to specify feature edge refinement in levels e,g.

file "s1.eMesh";
levels ((0.000001 2)(0.000002 1));

Actually i deleted all the version of open foam before as you described previously as shown bellow and installed only OpenFOAM v2.4.x and followed your procedure exactly. so it is the only open foam version on my computer for now. however, i ignored the error and just ran the simulation, the first one crashed (RAM most likely) as a struggled to reset the ubuntu parallel and now the second one has been running for few hours now and still running smoothly without the log file, if all goes well, i will run it again with the log file and send you the log file straight away.

Also, my shel refinement iteration goes all the way up to 100 iterations since i changed my region refinement from to this takes a long time

thanks

Quick answer: snappyHexMesh's way of seeing the geometry depends on the mesh at a certain point in meshing.
For example, if you run blockMesh with the "blockMeshDict" you provided, and if you only have the "s1.stl" geometry in "snappyHexMeshDict", then the geometry is floating inside one of the base mesh cells. This means that snappyHexMesh will not be able to see anything of the "s1.stl" geometry, because not even one internal cell edge goes through the STL surface.

Hello Bruno,

Thanks for your reply, i thought so at first. however, i came to understand otherwise, i tried a various range between this two options in my blockmeshdict:

and

for values above (20 20 20) i had to increase the , for some reason it reduces the load on my RAM.


anyhows, from my experience, i came to the realisation that the base mesh refinement didn't make any difference to the refinement of the internal cells within my geometry, so long i increased the feature edge refinement and surface edge refinement. i realised some improvement (not much) by increasing the region wise refinement level to an extent as increasing it to level above 9 and 10 for both volume mode and inside mode respectively leads the meshing process to crash as it exhaust all the memory (58.5 gb RAM allocated).

Also the main reason for decreasing my blockmeshdict value was to reduce the multiple extra domains associated with i know i can delete the extra domains using the subset code bellow, however it doesn't really eliminate all the domains, but it surely reduces the number of extra domains significantly (ridiculously). i am guessing the domains associated with the base mesh gets deleted, but i reckon extra domains are created because of the poorly refined internal regions in the s1-s5 geometries.

but i don't know!........this is all confusing and i ve just a month to hand in my results, for progressing to final year.

I am considering just running the simulation as it is, been stuck trying to mesh it for more than 4 months now.

Hi Nasir,

The refinement levels imply that it's the number of divisions that each original cell will be divided into. For example, level 3 means that each initial cell will be divided into 2*2*2 = 8 cells in each direction.

For example, if the original mesh of "2 4 2" was all defined to have a refinement level of 10, it would mean that all directions would be divided into 1024 cells per original cell, resulting in the final mesh resolution of "2048 4096 2048" ~= 17179.87 million cells.

If you change your original mesh to "30 30 30", you should reduce the number of refinement levels on all surfaces and regions, otherwise you get a final mesh resolution for level 10 of "30720 30720 30720"... which a lot of cells...

My questions are then this:

1. Do you need to mesh inside the objects like "s1.stl"? Or can you simulate with just a surface with no thickness (namely a baffle) for each geometry?
2. Have you tried the strategy isolate and conquer? In other words, first mesh just one of the critical geometries (such as "s1.stl"), to first try and understand what's going wrong?

Best regards,
Bruno

Hello Bruno,

Ahhh i see now get it. thanks for your prompt reply once again.

well, to be honest, since its a research project, i would like to test different materials and or coatings, which could sometimes result in a model with different surface vs internal thermal attributes, e.g thermal conductivity. also i thought evaluating the thermal storage in the s1-s15 geometries would add to the quality of the research.

i just saw this now prior to morphing phase:

which means that snappyhexmesh is definitely converting some faces into baffles. i am guessing bellow certain geometry thickness, snappyhexmesh converts it into baffle.

i did try to "isolate and conquer" but the simulation seems to take longer so i just went back to "complete and conquer". however i ve ran so many simulations, literally non stop for the past 5 months, with different configurations to evaluate impact of various parameters, specifically on the cell zone issue, that has been my issue from the first week of setting up the case, i will try that but i think i would just try to get some results for now. this could be one of the limitations of my my methodology i guess.

ok seems to be going ok now, will reset the simulation and send you the log file in about 8 hours i reckon. you will find my log file very interesting lol i can see allot of errors and stringing........

thanks

Nas

ok sir, the simulation did crash as a result of the multiOloop. however, i just tried to run your procedure as specified above a couple of times and now its updated without any permission denial, what i didn't do was sign in as a root user before running the last command.

the result can be seen bellow, i will run the simulation again and send you the log file as planned.

thanks allot bruno will update in few hours

Hello Bruno please find attached a copy of the log file.

thanks

nas

Hello Bruno,

please do you understand the implication of this warning message and how to go about resolving it, i think this could be an associated problem with converting some zones into baffles.

Hi Nasir,

It didn't work :( The log file states right at the start the following line:
which means you ran with OpenFOAM 2.4.0 and not 2.4.x :(

Yes, that does look like it could be one of the origins of the problem. Furthermore, that sounds like it's something that is already fixed in the OpenFOAM-history repository: https://github.com/OpenCFD/OpenFOAM-history
The problem is that if you're having trouble building 2.4.x, building OpenFOAM-history is a bit more complicated.

If I remember this correctly, snappyHexMesh has a meshing strategy that requires creating baffles temporarily in order to be able to mesh certain situations. Then after the meshing operation is completed, it dissolves the baffles back into the standard internal mesh.

I was more worried about the meshing stage first, instead of trying to simulate with a not-so-good mesh, but OK... as the saying goes: "optimum is the enemy of good".

The usual beginner mistake is to go straight to the final geometry and to try and mesh it. Then to try and fix the meshing with only the final geometry. Given that there are too many variables and since no extra complexity is removed from the geometry, the full range of problems takes a lot longer to solve :(
This is why an isolate-and-conquer strategy can remove a lot of the complexity out of the problem and make it faster to reach a solution that might solve all of the problems for the other geometrical components.

This definitely isn't good news :( Even though you are running inside the folder "OpenFOAM-2.4.x", the resulting path is pointing to OpenFOAM 3.0? :(

The following wiki page explains how to deal with using OpenFOAM's shell environment and how to make sure that only one version of OpenFOAM is used for each terminal: http://openfoamwiki.net/index.php/In...with_the_Shell

Best regards,
Bruno

Hello Bruno,

Thanks very much for your reply, i will now go through the shell environment wiki page and make sure i have openFOAM 2.4.x running, run the simulation and send you the log file, within the next couple of hours.

with regards to my case, i think i will simplify the geometry allot further by having the s1-s15 as sheets with zero thickness. however, if i model them as sheets with zero thickness on solid works, i am wondering if there is a way to add thickness to a surface geometryor or surface mesh on OpenFOAM?

i can see now that the new openFOAM history repository 3.0.x installation process seems straight forward-ish, i will give it a try also.

and you are absolutely right, i think i will still work on the mesh for another couple of weeks, before running the simulation.

Kind regards

Nas

Hey, sorry guys, I've been on and off planes the past few days. It looks like you've covered some ground already...did Nasir find some more memory or would you still like me to get 2.4.x installed for this?

Hi Nasir and me3840,

@Nasir:
Baffles are two-sided patches with zero thickness. They will be the likely result of meshing the sheets with zero thickness. I think you can still assign heat transfer properties to the baffles (e.g. heat transfer coefficient), but they will continue to have zero thickness.
"Inflating" the baffles is probably possible with a dynamic mesh operation, but I've never done it myself.

@me3840:
Thanks for offering to look into this, but I believe that Nasir needs to rework the original geometry. The current geometry results in a very complicated meshing operation that leads snappyHexMesh to simply crash because it got confused.
In addition, the geometry is fairly complex and debugging this issue is like finding a needle in a very large haystack :(

Best regards,
Bruno

Hello Bruno and me3840,

Thanks for your replies and patience bruno, the meshing kept on crashing, as i forgot to reduce the refinement levels after adding in snappyhexmeshdict.

dont panick! i am aware i am using OpenFOAM 30, i have simplified the geometry by removing the holes on the S1-S15 sheets. please find the link for the log file attached bellow. i will now try to make sure i have openFOAM 2.4.x and 3.0.x running, and will send you the various log files before and after following your procedure, if there are any changes as to what i should be doing, please let me know. i will try to get the log file for your procedure within the next couple of hours.

https://www.dropbox.com/s/qpmypl0qfk...exMesh.gz?dl=0

kind regards

Hello Bruno,

Apologies for the delay, took me sometime to figure out the SHELL environment
I can now assure you i am using of30x.

I will post the outcome and we can proceed.

kind regards

nas

Hello Bruno,

I ve now run the simulation on of30x, please find the attached outcome. i am wondering if i still need to download and install of24x or can i follow your procedure on of30x and it should be fine, as i am guessing of30x is just an extension of 0f24x.

note: i ve set for this particular run (on of30x)
kind regards

Nasir

Hello Bruno,

ok right back where we started, i can assure you, i now have op24x running, and i ve updated your bug fix as shown bellow, i am going to run the simulation now and post results, within the next couple of hours.

kind regards

nas