Skip to content
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

solve grid mean equations explicitly #343

Merged
merged 1 commit into from
Oct 8, 2021
Merged

solve grid mean equations explicitly #343

merged 1 commit into from
Oct 8, 2021

Conversation

yairchn
Copy link
Member

@yairchn yairchn commented Oct 3, 2021

No description provided.

@@ -351,11 +351,11 @@ function SP(namelist_defaults)
namelist["meta"]["casename"] = "SP"

# this case is resolution dependent, we should check why
namelist["grid"]["nz"] = 256
namelist["grid"]["dz"] = 8
namelist["grid"]["nz"] = 128
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SP does not work with dt=1 I had to make dz different. Change in the resolution effect SP, I have seen it before - I think something is off with the way the case is coded

@@ -128,7 +128,7 @@ function default_namelist(case_name::String)
namelist_defaults["thermodynamics"]["quadrature_type"] = "log-normal" #"gaussian" or "log-normal"

namelist_defaults["time_stepping"] = Dict()
namelist_defaults["time_stepping"]["dt"] = 10.0
namelist_defaults["time_stepping"]["dt"] = 7.0
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at default dt =10 some minor instabilities still appear in diffusive cases such as dycoms and in the lower (boundary layer) of ARM

write_profile(Stats, "diffusive_flux_qt", edmf.diffusive_flux_qt)
write_profile(Stats, "diffusive_flux_u", edmf.diffusive_flux_u)
write_profile(Stats, "diffusive_flux_v", edmf.diffusive_flux_v)
# write_profile(Stats, "diffusive_flux_h", edmf.diffusive_flux_h)
Copy link
Member Author

@yairchn yairchn Oct 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could either remove these diagnostics of handle them properly - depending on what do you think? These are useful diagnostic in then future but the entire diagnostic mechanism would probably change

GMV.QT.tendencies[k] += (GMV.QT.new[k] - GMV.QT.values[k]) * TS.dti
GMV.U.tendencies[k] += (GMV.U.new[k] - GMV.U.values[k]) * TS.dti
GMV.V.tendencies[k] += (GMV.V.new[k] - GMV.V.values[k]) * TS.dti
function GMV_update(grid::Grid, GMV::GridMeanVariables, TS::TimeStepping)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I move 'update' from 'src/Variables.jl' to here - I believe it is more correct for this function to be here - in the future we could collated all update functions (up, en, gm) into a single function

tendencies = field(grid, loc)
if kind != "scalar" && kind != "velocity"
print("Invalid kind setting for variable! Must be scalar or velocity")
end
return new{typeof(values)}(values, new, tendencies, loc, bc, kind, name, units)
return new{typeof(values)}(values, tendencies, loc, bc, kind, name, units)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no more 'new' in GMV!

@yairchn yairchn force-pushed the yc/explicit_gmv branch 3 times, most recently from 4ba3b53 to 40dea7b Compare October 3, 2021 17:08
Copy link
Member

@charleskawczynski charleskawczynski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like some of the results have degraded (e.g., some pretty strong oscillations)

@yairchn
Copy link
Member Author

yairchn commented Oct 3, 2021

It looks like some of the results have degraded (e.g., some pretty strong oscillations)

yes it was time-stepping , I updated the time steps lets see how it looks now.

@yairchn yairchn force-pushed the yc/explicit_gmv branch 2 times, most recently from 9456b52 to e1dbb55 Compare October 5, 2021 05:29
src/Operators.jl Outdated Show resolved Hide resolved
@yairchn yairchn force-pushed the yc/explicit_gmv branch 5 times, most recently from 1012f5d to d059f09 Compare October 8, 2021 16:33
Copy link
Member

@charleskawczynski charleskawczynski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bomex / life cycle results are now looking better with the smaller timestep.

@yairchn yairchn force-pushed the yc/explicit_gmv branch 3 times, most recently from 96f3688 to d903cbf Compare October 8, 2021 17:50
@ilopezgp
Copy link
Contributor

ilopezgp commented Oct 8, 2021

Neiuwstadt needs a smaller tilmestep (see contours).

@yairchn yairchn force-pushed the yc/explicit_gmv branch 4 times, most recently from 01377e7 to ac2cd46 Compare October 8, 2021 20:45
@yairchn
Copy link
Member Author

yairchn commented Oct 8, 2021

Bors r+

@bors
Copy link
Contributor

bors bot commented Oct 8, 2021

@bors bors bot merged commit 745fce4 into main Oct 8, 2021
@bors bors bot deleted the yc/explicit_gmv branch October 8, 2021 21:23
@charleskawczynski charleskawczynski mentioned this pull request Oct 8, 2021
charleskawczynski referenced this pull request Oct 16, 2021
414: Bump version r=charleskawczynski a=charleskawczynski



Co-authored-by: Charles Kawczynski <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants