Code modifications
Finding and modifying the vertical integral
The idea is to do this by modifying the underlying subroutine. Hopefully one exists.
Geopotential used in NH model: called phinh_i
(only at interfaces).
In order to calculate a vertical integral, either phinh_i
or dp3d
must be referenced.
So: plan for tomorrow. 0) Ensure deep atmosphere 2016 base state is available. (Looks to be true!)
- Modify EOS + elem ops following MT document
- Identify as many vertical integrals as possible. Figure out how to change them.
Assumptions
- We assume that
uses a constant
defined in the code by
use physical_constants, only: g
. This means that computation ofdphinh_i
does not need to be changed. - We assume that
, i.e. midpoint values of interface quantities can be reconstructed by averaging.
theta_hydrostatic_mode=.false.
. We disregard the case of a hydrostatic-but-deep atmosphere because, honestly, who would use that?
List of changes
dp3d
Calculating
In order to do this we first determine a way to calculate on model
interfaces as well as model levels.
Here is the first complication: midpoints are defined to be in the middle of the interval and
. If
is not a height coordinate, then taking the average of
and
may not give the geometric midpoint of the interval. In the proofs of conservation
provided in Taylor (2020), Eqn 30 shows that this is good enough for the moment. This is consistent with the
element_ops.F90
routine
for calculating it at midpoints.
These are added to the element_ops.F90
file. The get_radius
subroutine
is not publicly exported because we assume it's only usable in theta_hydrostatic.
get_field
and get_field_i
must be called to calculate radius or r_hat.
Modifying dp3d calculation
So dp3d
is calculated at initialization, but grepping for dp3d
shows that
the only assignments to dp3d are through time stepping. Therefore, test initialization
will need to be modified to calculate dp3d
with the correct pseudodensity. However, so long as our updates
to the CAAR routines are internally consistent, we needn't change how dp3d
is used after it is initialized.
EOS changes
At line 176 in eos.F90
calculates .
In the shallow HOMME formulation,
Using the definition
line 178 calculates
and then line 182 calculates
Therefore line 176 is an intermediate quantity that allows for the calculation of nonhydrostatic pressure by line 178,
and the exner function by line 182.
Therefore in the deep HOMME formulation,
and the rest of the derivation remains the same.
Todo:
-
Add parameter to control deep/shallow
-
Modify IMEX system
-
Sleuth initialization to figure out where
dp3d
is first calculated. -
Modify prognostic equations
-
Note:
tests_initialize
requiresphi_from_eos
- But: doesn't seem to use dp3d.
/home/owhughes/E3SM/DA_HOMME_E3SM/components/homme/src/dp3d.grep.log
contains all potential problems caused by redefinition of dp3d
Find calculation of derived%gradphi
--> fixed.
Questions:
Is this consistent?
elem(ie)%state%ps_v(:,:,np1) = hvcoord%hyai(1)*hvcoord%ps0 + &
sum(elem(ie)%state%dp3d(:,:,:,np1),3)
dpnh_dp_i(:,:,nlevp) = 1 + ( &
((elem(ie)%state%v(:,:,1,nlev,np1)*elem(ie)%derived%gradphis(:,:,1) + &
elem(ie)%state%v(:,:,2,nlev,np1)*elem(ie)%derived%gradphis(:,:,2))/gravit - &
elem(ie)%state%w_i(:,:,nlevp,np1)) / &
(gravit + ( elem(ie)%derived%gradphis(:,:,1)**2 + &
elem(ie)%derived%gradphis(:,:,2)**2)/(2*gravit)) ) / dt2
Is it appropriate to use a constant in the definition of
?
Combining eq 4 with definition of causes r hats to cancel. Is that correct?