fireII R5 and R11 examples in hy2Foam do not run

[iainsymthe]

Both examples fireII_R5 and fireII_R11 do not run out of the box with Allrun. These directories do not have the 0 directory as in fireII_NR

[vincentcasseau]

Hi Iain,

I know. Alex pushed my agenda forward by requesting the dev-isro-1 branch to be merged with master. I decided to upload the fireII test cases setups anyway to illustrate the new changes. The restart time folder of R5 will be the latest time folder of NR and the restart time folder of R11 will be the latest time folder of R5.

I will run the simulations once I am be done verifying species diffusion and energy/temperature boundary conditions.

Regards, Vincent

[iainsymthe]

Thanks, Vincent. I was able to copy the 0 folder from the NR case, cp the N2 file to N, O, NO, NO+ etc and change all the uniform values to 1e-30 and it runs fine. As an aside, the grid shown in the cases look like they are uniform and do not pack points near the object.  I have seen some papers that say the first point off the object is 2microns.   On Wednesday, December 30, 2020, 01:08:03 PM CST, Vince notifications@github.com wrote:

Hi Iain,

I know. Alex pushed my agenda forward by requesting the dev-isro-1 branch to be merged with master. I decided to upload the fireII test cases setups anyway to illustrate the new changes. The restart time folder of R5 will be the latest time folder of NR and the restart time folder of R11 will be the latest time folder of R5.

I will run the simulations once I am be done verifying species diffusion and energy/temperature boundary conditions.

Regards, Vincent

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Gaurav1299]

Dear Vincent, I was trying to run the R11 cases on fireII. As you told in your previous mail, I initially ran fireII_NR and created the restart folder of fireII_R5 as the latest folder of fireII_NR, and the simulation run perfectly for fireII_R5. I then created the restart folder of fireII_R11 using the latest time folder of fireII_R5 but the simulation stopped at time 5.23e-7 with the following error message (the attached image). I had used the maximum CFL number as 0.2. I had tried to run the fireII_R11 independent of fireII_R5 and fireII_NR but still, it is not working. I would be very grateful if you could please help me.

Regards, Gaurav Sharma

[vincentcasseau]

Hi Gaurav, Are you using the setup provided in R11 (please double-check your chemistryProperties dict)?

I will also take this opportunity to answer previous questions:

1. why aren't the results folders given for the NR, R5 and R11 non-adiabatic wall cases?

Upon running these cases, you should notice that the carbuncle effect is present as a result of using a numerical scheme (KNP) that is not adequate for very high Mach number flows (Mach 39 here). I wish we could run the same simulations with AUSM+up to show to true potential of the thermophysical library. Please correct me if I am wrong but I don't think this scheme has been made open-source by the OF community, under a license that fits this project.

2. the grid shown in the cases look like they are uniform and do not pack points near the object. I have seen some papers that say the first point off the object is 2microns.

Correct, but I wouldn't be able to run the simulations on my laptop. I may upload this grid once point 1. is fixed and ask someone to commit the results.

Regards, Vincent

[Gaurav1299]

Dear Vincent, Thank you for the reply. I think the case will run fine now.

Regards, Gaurav Sharma

[Gaurav1299]

Dear Vincent, I double-checked my chemistryProperties dict and corrected a mistake that I was doing. I now initialized the fireII_R11 case with the latest time of fireII_R5 with the correct dict. The simulation ran but stopped at a later stage (the error is shown in the attached image).

The time step is very small (e-27) and it looks like the simulation is diverging.

I would be very grateful if you could please help me.

Regards, Gaurav Sharma

[vincentcasseau]

What is your max CFL? Are you using the exact same setup as the one provided for R11?

[Gaurav1299]

Dear Vincent, The max CFL number that I am using is set to 0.2. I am using the exact same setup for R11 (the latest commit, the one with the VT model LeMANSMWP). I have run the simulation thrice and am getting the same error. I would be very grateful if you could help me run this simulation.

Regards, Gaurav Sharma

[vincentcasseau]

I committed the results folders I got a while ago in commit 29c3787. For the reasons stated above, I put them in a temporary folder. I haven't had much time to go through them again. Please first compare the R5 folders. Thanks

[Gaurav1299]

Dear Vincent, Thank you very much. I will do the needful and get back to you.

Regards, Gaurav Sharma

[Gaurav1299]

Dear Vincent, Thank you very much the simulation is running fine. I compared the results obtained from the simulation and that of the FIre 2 paper that you mentioned in your Ph.D. thesis paper. The heat flux values were not matching. Is this due to the carbuncle effect that you mentioned earlier?

Regards, Gaurav Sharma

[vincentcasseau]

Hi Gaurav,

I am glad it works. Yes, but also:

• first layer height is 5 times larger (already reported by Iain)
• the sigma1 coefficients in the thermo2TModel dictionary are default values (1e-20 in Hash et al., 2007)

Regards, Vincent

[iainsymthe]

Vincent: I was trying out the Orion107km example which runs to completion but then crashes as shown below.  The problem is that because of the crash, the job does not exit - the processes have to be manually killed.  I was running this example on 36 cores. Finalising parallel run* Error in dsmcFoam+': double free or corruption (!prev): 0x0000000002cfb0f0 ****** Error indsmcFoam+': double free or corruption (!prev): 0x000000000349d5e0 ** Error in dsmcFoam+': double free or corruption (!prev): 0x000000000314e280 ****** Error indsmcFoam+': double free or corruption (!prev): 0x00000000037b3ef0 *======= Backtrace: ================ Backtrace: =========/lib64/libc.so.6(+0x81299)[0x2b813bd98299]/lib64/libc.so.6(__cxa_finalize+0x9a)[0x2b813bd5105a]OpenFOAM/iain-v1706/platforms/linux64GccDPInt32Opt/lib/liblagrangian+.so(+0xbf23)[0x2b8138cdbf23] I see a similar problem when running snappyhexMesh in the Allrun script ...After snappyHexMesh finishes I see the following again in liblagranian.so ... Finished meshing without any errorsFinished meshing in = 10.31 s.End Error in `snappyHexMesh': double free or corruption (fasttop): 0x0000000001bd3350 ======= Backtrace: =========/lib64/libc.so.6(+0x81299)[0x2ba54dd4f299]/lib64/libc.so.6(__cxa_finalize+0x9a)[0x2ba54dd0805a]/home/user/OF/OpenFOAM-v1706/platforms/linux64GccDPInt32Opt/lib/liblagrangian.so(+0x10853)[0x2ba54ffbd853]======= Memory map: ========

[timteichmann]

To make things a little clearer I have created a separated issue for the dsmcFoam+ error raised by Ian. Please see issue #71.

[iainsymthe]

Tim/Vincent: Thanks for your response.  I had done a clean reinstall in December 2020 - built everything from scratch (ThirdParty, OFv1706 and the hystrath library).   Also, for the Orion107K problem, the controlDict has the endTime set as 70 s, but I see the solution reach close to steady-state in about 2-3 second or running.  My definition of SS is "weak" in that I monitored various variables using probes in about 11 locations and saw that temp does not change much (see attached png).  I also see that the temp in the initial time is 0, not the initial set value of 217K.  Is this something you have seen as well? Thanks Iain

On Monday, April 5, 2021, 01:28:17 PM CDT, Tim Teichmann ***@***.***> wrote:  

To make things a little clearer I have created a separated issue for the dsmcFoam+ error raised by Ian. Please see issue #71.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.