-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix to the calculation of constant outflow rate in the y-direction #16
Conversation
…lane in the x-direction (ie)
Small change to a part of the code that @bss116 and I only added recently for use in a validation case. @bss116 the reason that I saw this was that I was trying to alter the formulation of the flowrate forcing to make sure that we do not average over the buildings (mask them out). In doing this I noticed that this forcing actually only averages over the outlet plane (can only read this from the code because of the use of The other thing that could also be done as part of this is to change what it averages in the vertical direction. If we always have a block at |
Also @bss116 I think this explains why the wind direction didn't perfectly match up in that validation simulation - We were averaging along a y-z plane at index |
@tomgrylls I noticed before that the average velocity of the full domain diverged slightly from what was set by the flowrate, but not by as much to make me concerned about it. In fact I thought it had to do with the blocks not being discounted in the flow rate. However averaging only over the outflow plane could be the reason for it and if it has any impact I would expect more stability in the resulting forcing, and potentially less of the slow transients we experienced. So I definitely support making the change to the forcing. |
This sounds a bit patchy, what if there are blocks at the outlet plane, then this definition would not be right. |
Note - @bss116 and I discussed and a good solution would be to create an additional subroutine in |
…y, not timed by area
The latest commits address issue #38:
@tomgrylls lastly I wanted to change the use of |
@tomgrylls got it. it is |
src/modstatsdump.f90
Outdated
@@ -842,7 +844,8 @@ subroutine statsdump | |||
varsxy(:,13) = uwxyik(kb:ke) | |||
varsxy(:,14) = wthlxyk(kb:ke) | |||
varsxy(:,15) = vwxyjk(kb:ke) | |||
|
|||
varsxy(:,16) = udef | |||
varsxy(:,17) = vdef |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now if we ignore inflow-outflow conditions, are the necessary variables for these flow forcings being read for both cold- and warmstarts (in modstartup.f90)?
The latest commits change the outflow forcing to exclude the cells occupied by buildings and adds a volume average flow rate forcing, addressing issues #38 and #26. |
A quick update: @tomgrylls and I talked about the flow rate calculations. I will make a few changes and run a couple more tests and then this should be good to go into 0.1.0. Will let you know as soon as this is ready. |
I have now completed the tests for fixed outflow rate and new volume flow rate. I used a symmetric test geometry with four blocks and tested separately a forced flow along u and v wind direction for both outflow rate and volume flow rate. There is some variability between the cases but the pressure gradient forcing, average wind profiles, vertical fluxes etc. look reasonably similar that I think the forcing is doing what it is supposed to do. @tomgrylls Do you think this is good to go? If so I will go ahead and merge it. |
Sorry the labels are white, if you click on the image you can see which test case it is. |
@dmey Could it be that there is something wrong with travis for mac again? I ran these simulations on mac and it worked just fine. |
@bss116 I have not had time to go through the source code in detail but I think that the discussed and displayed tests should provide a very good indication of all that is in this pull request from my understanding. I am happy with these results so will approve. |
Ah I cannot review as is my pull request |
@bss116 if you are OK with this can you please approve and squash merge? |
The calculation of
vout
andvoutold
inmodforces.f90
has been corrected.Plus minor corrections to a typo and error warning messages in modboundary.f90.