firemodels / fds

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

coupling FDS to LES atmosphere model (PALM) #12399

Open alenamalyarenko opened 7 months ago

alenamalyarenko commented 7 months ago

Kia Ora, I'm working on coupling FDS and PALM - one-way coupling from PALM to FDS to begin with.

I've successfully initialised FDS with 3D field output from PALM, and struggling with boundary conditions (lateral boundaries of the domain). I've created a new type of surface for the coupled boundary ( surface "coupled" with open cells at the boundary). I'm now trying to modify subroutine velocity_bc accordingly. I've attempted to read in 2D fields, similar to how boundary conditions work in climate/ocean models, but I understand that I have to work within the EDGE loop.

Does it make sense to prescribe UVW at all four boundaries, provided the domain is sufficiently large, in a similar fashion to wall-of-wind code? I'm planning to start from a wind field that does not change in time, and progress from there.

https://github.com/firemodels/fds/blob/21dd4292df039d76e2a99ccd73c3c1042a666c78/Source/velo.f90#L2160

Could you recommend the appropriate treatment for tracers? Is there anything I need to worry about regarding the pressure solver? Is anyone working on something similar and willing to share their experiences?

Many thanks

mcgratta commented 7 months ago

Eric -- could you take a look at this and pass it on if you think someone is better equipped to answer.

ericvmueller commented 7 months ago

Is this coupling dynamic, or are you obtaining a single UVW field from PALM that you want FDS to maintain at the boundaries throughout the simulation? I guess the reason you cannot use WIND boundaries is that you have variation in x/y over the boundary and not just z?

I wonder if we can co-opt the logic of the synthetic eddy method but instead take in values from a file. For example, here the local normal eddy velocity (VEL_EDDY) is added to the pressure at open wind boundaries https://github.com/firemodels/fds/blob/21dd4292df039d76e2a99ccd73c3c1042a666c78/Source/pres.f90#L192-L204

and this velocity varies in 2D over the boundary surface. In this case it is based on a statistical model for turbulent eddies ...but I could see it coming from an external source https://github.com/firemodels/fds/blob/21dd4292df039d76e2a99ccd73c3c1042a666c78/Source/pres.f90#L163-L170

But perhaps Randy can tell us how crazy of an idea that is.

How did you handle coupling to WRF, @johodges?

alenamalyarenko commented 7 months ago

The goal is to have online 2-way coupling eventually (UVW + temperature + ..? ). I'm starting with offline 1-way coupling: reading PALM output from files, and yes, it changes in time and space.

I've obtained a single 3D field ( XYZ) from PALM to initialise the model, and I've set up 3D fields for (XZ/time YZ/time) for lateral boundaries, to have both space and time-varying boundary conditions. I'm happy to read just one field (for the first time step) from netCDF files for now, and add reading the correct time step later.

From my experience with ocean/climate models, I'm used to over-writing the boundary cells with values from a file towards the end of the time step, and then letting the model handle the solution in the next time step. With the eddy velocity option, is this the additional forcing added to the wall of wind (U_WIND) and the existing solution (UU)?

rmcdermo commented 7 months ago

Sorry I was offline for a few days...

Usually, the ABL simulations are at a coarser resolution than FDS (I assume that is the case here as well?).

If so, I suggest we proceed in two steps:

  1. Get the mean fields for U_WIND, etc., to vary in the lateral directions (they already vary in z and time).
  2. Devise a plan for matching turbulent statistics. a. This could be with explicit 2D fields, which sounds like what you are trying. b. Or using a synthetic eddy method on top of the means.

I am interested to help with this. It is something we have thought about for some time, but never really got beyond just mean velocity. Adding temperature and water vapor would be a good improvement.

Can you send me a simple test case that we can start working together on?

ericvmueller commented 7 months ago

My idea of using VT%U_EDDY etc was just an initial way to do the lateral variation since we already have this framework of 2D arrays applied to the boundaries. For clarity, maybe it would involve renaming them as VT%U_WIND or whatever (which would contain the background flow and then we could still superimpose turbulence in the SEM routine if needed).

I made a kind of simple hack that sets the U/V/W_EDDY arrays based on the initial wind field and then just holds them (assuming there are no SEM eddies added). A next step would be time updates and then consideration of other variables.

Just an idea though, I'm sure you have a more elegant way forward, Randy

(also this is initially assuming a scenario where we already have data at the correct resolution in a csv file)

rmcdermo commented 7 months ago

Certainly not claiming I have a more elegant idea. I just want to make sure we coordinate this effort, so that we don't end up with different schemes for PALM and WRF, for example.

rmcdermo commented 7 months ago

@alenamalyarenko, We had a look at the locations of the U_EDDY, V_EDDY, W_EDDY today. Eric and I both think this is probably easier than we were making it out to be yesterday. From your perspective, you can just think of populating the 2D arrays with the three components of velocity at the cell faces on the external mesh boundaries. The image below is for a boundary normal to the y direction in FDS. Just take the (u,v,w) from PALM and do whatever interpolations you need to do to get values at the face centers.

Screenshot 2024-02-02 at 5 16 03 PM
alenamalyarenko commented 6 months ago

@rmcdermo thanks! The 2D arrays thinking is definitely where I've started from!

populating the 2D arrays with the three components of velocity at the cell faces on the external mesh boundaries

Would you still be populating U_EDDY arrays to be added to the velocity field in the pressure solver, or just overwriting the UVW velocity arrays directly in velocity_bc? I'm tempted to do a VENT loop at the end of velocity_bc, and overwrite UVW variables for each vent if n_eddy=-1. This approach would probably also work for temperature fields later.

ericvmueller commented 6 months ago

I think I misinterpreted the application of VEL_EDDY in VELOCITY_BC, as this is not applied for open wind boundaries.

https://github.com/firemodels/fds/blob/6a53de908e7a57f8d2af4c1c345d05b9d997894a/Source/velo.f90#L2192-L2196

So we have a mismatch were it is applied in the normal direction but not in the tangential. If you run the sem_test.fds verification case with a wind boundary rather than an inlet you will see the fluctuations do not appear properly applied in the tangential directions, only the normal.

This is something we probably want to consider for the use of SEM, @rmcdermo. But for you @alenamalyarenko I'd consider using these lines to set your tangential velocity. If you're using the U/V/W_EDDY arrays with the components specified at the vent face centers just be aware of needing to interpolate onto the staggered grid.

https://github.com/firemodels/fds/blob/6a53de908e7a57f8d2af4c1c345d05b9d997894a/Source/velo.f90#L2167-L2185

rmcdermo commented 6 months ago

@ericvmueller Have a look at the latest code. SEM should now be using VEL_EDDY to compute the tangential components and correctly compute the stresses. This should allow @alenamalyarenko to just use the face centered values for all three velocity components.

ericvmueller commented 6 months ago

Nice - the only question I have is now it seems the use of SEM with an open boundary ignores tangential U/V/W_WIND.

Putting aside the case of model coupling for now, if you want to have synthetic turbulence and a mean tangential component to the velocity is this possible? I see that U/V/W_WIND are used to compute tangential eddy advection in SYNTHETIC_TURBULENCE (turb.f90), but I don't see that they are added to VEL_T in VELOCITY_BC so we are kind of half considering this case (correct me if I'm wrong).

rmcdermo commented 6 months ago

Yes, good point. Let me look more closely at thist.

rmcdermo commented 6 months ago

@ericvmueller Have a look at the latest commit and see what you think. It's not pretty. But I think we all need to sit down and overhaul this routine. We have too many hacks upon hacks at this point.

ericvmueller commented 6 months ago

Looks reasonable to me and should allow Alena to just continue with using those eddy arrays, as you say. Out of curiosity I will try this with that hack I made to use U/V/W_EDDY to hold a velocity field after reading in a csv file from a previous simulation. The tangential components should be much better with your fix.

rmcdermo commented 6 months ago

I've played with multiple meshes with SEM and looks like we are generating eddies independently on each mesh, which leads to discontinuities at mesh external boundaries. It will take some work to overcome this, but we should do it at some point.

For now, this should not affect Alena.

antoniomaze commented 6 months ago

Thanks, Randy for adding me to this chat. As I said what I would need for my project is a way to vary the wind along the X and Y other than Z. I see you working on it. Any idea if a solution will come shortly or if this will take many weeks?

rmcdermo commented 6 months ago

Sorry, at least many weeks.