firemodels / fds

Fire Dynamics Simulator
https://pages.nist.gov/fds-smv/
Other
673 stars 627 forks source link

Camp Swift case crashing on gnu linux #13678

Closed rmcdermo closed 3 weeks ago

rmcdermo commented 4 weeks ago

If I try to run the newly added Camp Swift case with the ompi_gnu_linux build on spark it crashes. (Note: you must update your firemodels/cad repo to run this case. Running in _db I found this error.

At line 1344 of file ../../Source/wall.f90
Fortran runtime error: Index '544830063' of dimension 1 of array 'pbar_p' above upper bound of 41

The line in wall.f90 is this:

B1%RHO_F = PBAR_P(BC%KK,B1%PRESSURE_ZONE)/(RSUM_F*B1%TMP_F)

So, seems like something is not initialized properly for BC%KK. Probably a particle.

To reproduce, compile any of the ompi_gnu_linux targets and run with -G option with qfds.sh

ericvmueller commented 4 weeks ago

This likely has to do with the issue I showed you about INIT regions in meshes with negative coordinates.

I have a fix I just want to run it through firebot.

FYI there's also some other details of the case I'm still tweaking/investigating so inputs might change. Sorry I probably jumped the gun pushing it.

ericvmueller commented 3 weeks ago

Ah I spoke too soon. My fix will clean up some extraneous particle insertion, but this looks like it has to do with the use of BC%KK as opposed to BC%KKG when CALCULATE_ZZ_F is called for a particle. As far as I know BC%KK is not really relevant for particles (for example I don't see it updated when particles move), so the value there is nonsense. But then I'm not sure why this hasn't cause an issue in other cases.

Probably @mcgratta can say if this usage is problematic.

drjfloyd commented 3 weeks ago

I think the solutilon is to define an integer variable KK at the top of CALCULATE_ZZ_F. Then in the SELECT CASE at the top of the routine set KK to BC%KK for WALL_INDEX and CFACE_INDEX or BC%KKG for PARTICLE_INDEX.. The anywhere in the routine where we use BC%KK and it could be a particle change it to KK.

mcgratta commented 3 weeks ago

II and IIG should be the same for particles. If we don't update both, I suggest we should, just to be safe.

ericvmueller commented 3 weeks ago

Okay, I'm going to work on making sure we assign II etc. wherever we assign IIG etc.

ericvmueller commented 3 weeks ago

@rmcdermo try again now with the ompi_gnu build and see if you get off the ground.

rmcdermo commented 3 weeks ago

OK, seems to be running fine now. Thanks!