firemodels
OBST snapping to center of coarse mesh at hybrid mesh boundaries
Here is an example showing the OBST snapping to different physical locations on a hybrid mesh discussed in the Dev meeting. The first screenshot shows the OBST definition in the input file, and the second shows the snapped grid.
This appears to be the correct behavior. That is to say, I think this is how we programmed it.
@johodges Thanks for the clarification. What else could we do in this case?
This came up during the discussion of meshing recommendations in the dev meeting. I think this has the potential to lead to numerical instabilities over time. Removing these mesh artifacts is the second step I take on the commercial jobs when colleagues are struggling with models crashing over time. The first step being checking for oddities in the pressure zones.
I usually recommend the user thicken the OBST such that the fine mesh snaps to to be aligned with the coarse mesh. In this specific case it would be like this:
I recall trying to make a toy problem like this before and never submitting it as an issue because I couldn't isolate it to just one factor like this. Usually models which crash in commercial jobs after they have been running for a while have 100k+ input lines with the failures occurring after 1-2 days of runtime. Avoiding this is one of those best practice recommendations that I make as part of the clean up, but it may be a red herring. I can play around with it a bit and see if I can reproduce a crash in a simplified manner related to this issue.
@johodges I think that this is something Pyrosim would be best to tackle, don't you think?
Agreed I think a fix for this would live in the pre-processor. The section on numerical instabilities notes this as a potential issue already "mismatched obstructions or hollow ducts at a mesh interface where grid resolution changes". It may be good to expand that to provide a bit more context similar to the "large number of automatically generated pressure zones" note. Thoughts?
@johodges Have you also tested MINIMUM_ZONE_VOLUME parameter in those cases with issues?
Is the best solution to just expand the obstructions in the finer mesh to match the coarse mesh? I would think we could do something like this at least in the first cell of the fine mesh adjacent to the coarse mesh. We could add a little transition OBST one cell width away from the coarse mesh. Something like in the image below, were we make a new OBST (blue outline) in the fine mesh that matches the end of the OBST in the coarse mesh (purple outline) and then from that transition OBST (blue) we make the OBST (green outline) at the more accurate resolution in the fine mesh, closer to the originally requested geometry. This way we resolve the geometry in the fine mesh more accurately and don't make it unnecessarily large (red dashed outline).
I think that would work, although it might be better to make the blue box 2 fine cells thick (1 coarse cell thick) in case the fine mesh is surrounded by coarse meshes and the OBST is at a corner.
Why not just throw a warning if a single OBST changes shape across a mesh boundary. For many, it may not matter because the coarse mesh is there simply to save on computing time and is not an important component of the simulation. Adding elements may add to confusion because then it will no longer be clear that the mesh boundary is responsible for the change.
Because there could be hundreds or thousands of warnings in many models where some CAD model is rasterized to the meshes in PyroSim. We already have a rasterization function that tries to make OBSTs that represent the original geometry in the meshes of different sizes. The end user wouldn't really know/care about this extra little OBST we add, they would just see that there would be a bit of 'bigger' geometry in the fine mesh at the boundary. We could even 'highlight' them in the modeling panel if we wanted to show people the transition OBST in when 'Preview FDS Blocks' is enabled.
To your point, we could add something like we do when holes are at mesh boundaries. Where we let the user know and then ask if they want us to expand the hole a bit past the mesh boundary.
We could say something like "You have geometry that is passing through mesh boundaries, would you like to add transition obstructions at those locations?" If 'Yes' we add them, if 'No' we do it the same way as we are now with potential instabilities. I can't think of a good situation where someone would say no, so we might just do the right thing and add the transition OBST, then explain how we do it in the user manual.
My comment was support for a change in Pyrosim rather than a change in how FDS handles the OBSTs crossing the mesh. We could have FDS flag a warning, but I do not think it is as high a priority. The cases where this is a problem are usually handled through a pre-processor rather than a text editor.
@johodges I think that the 1 cell depth should work, because at corners there would be more than 1 interface and each transition would be accounted for as needed into the finer mesh. I am making a test model that has a few bad situations in it for testing any changes we make. One thing I just noticed is that when we rasterize all geometry (including axis-aligned) and write that out to FDS input, the geometry in the FDS Actual Scene doesn't look the same as our FDS Block Preview. My guess is that we have slightly different rules for snapping geometry than FDS is using. We might need to dig into that a bit more for parity. I would expect that what you see in PyroSim's Block Preview would be the same as what FDS uses and there shouldn't be any adjustments needed by FDS as all of the geometry we write to the input file should already conform to the meshes.