dalesteam / dales Goto Github PK
View Code? Open in Web Editor NEWDutch Atmospheric Large-Eddy Simulation model
License: GNU General Public License v3.0
dales's People
Contributors
Stargazers
Watchers
Forkers
smartlixx xabipedru cloudresolvingclimatemodeling erwindebeus huangynj lochbika jakubfabian kevinnielson julietbravo ipelupessy rkrishn1 phaustin huangguanyu chiil jiahe23 mdebruine jiskattema mich4all mennoveerman leo-rain jchylik esiwace-s1 bartwarmerdam gedegroot sderoode zrxdaly martinjanssens yuribonanno franslql alessandrosav xliu0628 fjansson chanjeunlam yulongma rq314 vtquang194 rhhjanssen xiaofeifei00123 natalieth stevenvdlinden casparjungbacker ziyuwind karars94 esclapez vincentdefeiter tstoeterdales's Issues
Bug in modaradiation in case of warm start
It has turned out that the bug is in the subroutine radiation in modradiation, line 204:
if((itimerad==0 .or. timee==tnext) .and. rk3step==1) then
tnext = tnext+itimerad
<calls to radiation schemes>
In the case of the warm start, the initial (modraddata) "tnext" is set lower than post-restart "timee". Therefore, (modraddata) "tnext" is never updated and radiation schemes are never computed. This leaves the model run only with 0 radiative tendency of large-scale radiate tendency.
The proposed quick fix is:
if((itimerad==0 .or. timee>=tnext) .and. rk3step==1) then
tnext = max(timee-dt_lim,tnext)+itimerad
<calls to radiation schemes>
This will both:
a) set the tnext back on track in case of warm start in a consistent way
b) prevent running the radiation calculations btime/itimerad times
The other option is adding btime from modglobal to used variables, and adding lines:
if(tnext<btime) then ! fix for btime after warm start
tnext = btime+itimerad
end if
if((itimerad==0 .or. timee>=tnext) .and. rk3step==1) then
...
RRTMG crashes if backrad.inp is not sorted by descending pressure
I got a segfault in RRTMG when using a backrad.inp sorted in ascending order in pressure.
I propose DALES should check and stop with an error message instead, because the sorting requirement isn't obvious.
modradfull: MEM[...] used uninitialized in this function (as reported by gfortran)
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 48B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 56B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 64B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 72B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 80B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 96B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 104B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 112B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 120B]’ is used uninitialized in this function [-Wuninitialized]
dales/src/modradfull.f90:1924:0: warning: ‘MEM[(struct band_properties *)© + 128B]’ is used uninitialized in this function [-Wuninitialized]
gfortran warnings (50 occurrences): Equality comparison for REAL(8)
dales/src/modgenstat.f90:704.8:
if (qls==0) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsubgrid.f90:73.7:
if(cs == -1.) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1676.12:
if (Cskin(i,j) == 0.) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1690.11:
if(LE(i,j) == 0.) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1098.30:
if(Rib * L < 0. .or. abs(L) == 1e5) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1115.32:
if(Rib * L < 0. .or. abs(L) == 1e5) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1180.30:
if(Rib * L < 0. .or. abs(L) == 1e5) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1200.32:
if(Rib * L < 0. .or. abs(L) == 1e5) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1231.24:
if(Rib * L < 0. .or. abs(L) == 1e5) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:1248.26:
if(Rib * L < 0. .or. abs(L) == 1e5) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:477.27:
if((z0mav == -1 .and. z0hav == -1) .and. (z0 .ne. -1)) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:477.10:
if((z0mav == -1 .and. z0hav == -1) .and. (z0 .ne. -1)) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:484.11:
if(z0mav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:487.11:
if(z0hav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:496.74:
if(tsoilav(1) == -1 .or. tsoilav(2) == -1 .or. tsoilav(3) == -1 .or. tsoilav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:496.52:
if(tsoilav(1) == -1 .or. tsoilav(2) == -1 .or. tsoilav(3) == -1 .or. tsoilav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:496.30:
if(tsoilav(1) == -1 .or. tsoilav(2) == -1 .or. tsoilav(3) == -1 .or. tsoilav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:496.9:
if(tsoilav(1) == -1 .or. tsoilav(2) == -1 .or. tsoilav(3) == -1 .or. tsoilav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:499.9:
if(tsoildeepav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:502.71:
if(phiwav(1) == -1 .or. phiwav(2) == -1 .or. phiwav(3) == -1 .or. phiwav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:502.50:
if(phiwav(1) == -1 .or. phiwav(2) == -1 .or. phiwav(3) == -1 .or. phiwav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:502.29:
if(phiwav(1) == -1 .or. phiwav(2) == -1 .or. phiwav(3) == -1 .or. phiwav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:502.9:
if(phiwav(1) == -1 .or. phiwav(2) == -1 .or. phiwav(3) == -1 .or. phiwav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:505.74:
if(rootfav(1) == -1 .or. rootfav(2) == -1 .or. rootfav(3) == -1 .or. rootfav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:505.52:
if(rootfav(1) == -1 .or. rootfav(2) == -1 .or. rootfav(3) == -1 .or. rootfav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:505.30:
if(rootfav(1) == -1 .or. rootfav(2) == -1 .or. rootfav(3) == -1 .or. rootfav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:505.9:
if(rootfav(1) == -1 .or. rootfav(2) == -1 .or. rootfav(3) == -1 .or. rootfav(4) == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:508.9:
if(Cskinav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:511.9:
if(lambdaskinav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:514.9:
if(albedoav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:517.9:
if(Qnetav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:520.9:
if(cvegav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:523.9:
if(rsminav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:526.9:
if(rssoilminav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:530.9:
if(LAIav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:533.9:
if(gDav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:536.9:
if(Wlav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:567.23:
if(rad_shortw .and. albedoav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modsurface.f90:571.9:
if(albedoav == -1) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modtimestat.f90:818.12:
if (vars(2)==0) vars(2) = nc_fillvalue
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modtimestat.f90:820.12:
if (vars(3)==0) vars(3) = nc_fillvalue
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modtimestat.f90:822.12:
if (vars(4)==0) vars(4) = nc_fillvalue
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modtimestat.f90:824.12:
if (vars(5)==0) vars(5) = nc_fillvalue
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modchem.f90:1890.6:
if( sum(ql0) == 0.0 .or. (lcloudKconst .eqv. .true.)) then ! maybe < 0.01
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modchem.f90:1191.8:
if (dtmin.eq.kdtmax) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modbulkmicro.f90:702.11:
if ( jn == 1. ) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modbulkmicro.f90:153.9:
if ( timee .eq. 0. .and. rk3step .eq. 1 .and. myid .eq. 0) then
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modnudge.f90:150.8:
if (rtimee==0) return
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modstartup.f90:302.12:
if (wtsurf == -1) stop 'wtsurf not set'
1
Warning: Equality comparison for REAL(8) at (1)
dales/src/modstartup.f90:303.12:
if (wqsurf == -1) stop 'wqsurf not set'
1
Warning: Equality comparison for REAL(8) at (1)
namelist parameters
Some namelist parameters can appear in multiple lists.
thls in SURFACE, PHYSICS
isurf in SURFACE, PHYSICS
This causes trouble at the moment with the OMUSE interface, when starting from an existing case.
If this is changed, all cases should be checked.
Other namelists have parameters with the same name, e.g. dtav appears in many output and sampling lists. This is fine, since these are different parameters.
Crash in extremely stable conditions - TKE production at the surface
We have had a crash in the Dales surface scheme under stable conditions, over land. The symptoms are a sudden huge e12 - tendency at the surface, which causes the whole simulation to break and stop with a thermo crash a few steps later.
We run with isurf=4 - imposed surface fluxes. The crash occur in the evening when the heat flux is negative and the wind is very weak. The Obukhov length is then positive and small. A more stable surface layer -> smaller Obukhov length.
modsurface.f90, line 984:
phimzf = (1.+5.*zf(1)/obl(i,j))
...
dudz (i,j) = ustar(i,j) * phimzf / (fkar*zf(1))*(upcu/horv)
if the Obukhov length is small here, dudz can be very large.
modsubgrid, line 437++: dudz is used to calculate the tke tendency at the surface, via the shear term sbshr. A large dudz results in the large tke tendency which leads to the crash. Note that this is in a situation with very weak wind, so there should be very little shear.
Another related issue is that ustar is forced to be >= 0.01. Small Obukhov length corresponds to a small ustar, so without the limitation a small ustar would to some extent compensate for the large phi. note however that ustar also is present in a denominator, so that tiny values could potentially give problems here.
dthldz(i,j) = - thlflux(i,j) / ustar(i,j) * phihzf / (fkar*zf(1))
Fix
phimzf is the phi function in Monin-Obukhov theory. It is used here to determine du/dz at the first layer at height zf(1). There is also a psi function, which determines the actual velocity as function of z. Psi is defined as an integral containing phi, and is used in determining the Obukhov length.
- a) The phi function used is not valid when z/obl is larger than ~1. See e.g. Optis 2015
- b) The phi and psi functions used in Dales are not consistent with each other - the psi function reported to have the correct z/obl -> infinity limit.
a fix for a) is to add a hard cap on both phi functions at z/obl >= 1. This is one of the simplest phi functions listed by Optis, and it solves the problem in our case. Proposed fix here: CloudResolvingClimateModeling@8469307
ASCII output files are overwritten on warm starts
ASCII output files are overwritten on warm starts. It would be better to open them for appending. Currently seeing this for the RCEMIP branch of DALES, not yet sure its a general problem.
Affected files: tmser1, tmsurf, svNNNflx, flux1, flux2, budget
RCEMIP specific files: tmrce, rcemip
modlsmcrosssection missing if/endif
The file modlsmcrosssection.f90 deals with statistics of a heterogeneous surface.
Although the heterogenous surface patches can be used both for isurf=1 and 2 (and possibly more), the subroutines in modlsmcrosssection.f90 require variables that are initialised only in case isurf=1.
In other cases, the DALES run will crash without any warning.
Proposed correction:
line 74:
use modsurfdata, only : isurf
line 94:
if (lcross .and. (isurf .ne. 1)) then
lcross = .FALSE.
write (6,*) "Ignoring lcross, lsmcrossection currently implemented only for isurf==1."
endif
gfortran warnings (12 occurrences): Inequality comparison for REAL(8)
dales/src/modglobal.f90:614.6:
IF (fn_val /= zero) THEN
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modglobal.f90:615.8:
IF (y1 /= AINT(y1*half)*two) parity = .true.
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modglobal.f90:698.4:
IF (fact /= one) fn_val = fact / fn_val
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modglobal.f90:417.10:
if (dzf(k)/=dz) then
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modpois.f90:333.11:
if(z/=0.) then
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modsurface.f90:477.48:
if((z0mav == -1 .and. z0hav == -1) .and. (z0 .ne. -1)) then
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modchem.f90:1521.13:
where (seg_conc_mult .ne. 0)
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modchem.f90:1526.13:
where (seg_conc_mult_vert .ne. 0)
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modnudge.f90:156.8:
if (rtimee/=timenudge(1)) then
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modtimedepsv.f90:197.8:
if (rtimee/=timesvsurf(t)) then
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modtimedep.f90:350.8:
if (rtimee/=timeflux(t)) then
1
Warning: Inequality comparison for REAL(8) at (1)
dales/src/modtimedep.f90:283.8:
if (rtimee/=timels(1)) then
1
Warning: Inequality comparison for REAL(8) at (1)
gfortran warnings (4 occurrences): Possible change of value in conversion from REAL(8) to INTEGER(4)
dales/src/modradfull.f90:1603.10:
mbs = 0.
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at (1)
dales/src/modradfull.f90:1671.28:
band(ib)%gas_id(:) = gasesinband(1:ii)
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at (1)
dales/src/modfielddump.f90:234.14:
field = 0.
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(2) at (1)
dales/src/modfielddump.f90:249.10:
field=0.
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(2) at (1)
modtimidepsv doublecasting and update
There are two issues in modtimedepsv. The first one is that it is casting the same variable twice, but with a seemingly different array length.
l.152, 154:
call MPI_BCAST(timesvz(1:kflux),kflux,MY_REAL,0,comm3d,mpierr)
call MPI_BCAST(svst ,kflux*nsv,MY_REAL,0,comm3d,mpierr)
call MPI_BCAST(timesvz(1:kls) ,kls,MY_REAL ,0,comm3d,mpierr)
The second line is indeed correct. Surprisingly, it does not crash.
This is due to the fact that kls and kflux are both currently parameters set to the length 100. While this approach was originally ok, this approach is not consistent with the current approach used in modtimedep
Proposed solution for modtimedepsv :
- make kflux and kls variables consistent with modtimedep:
l.45-46
integer :: kflux
integer :: kls
- continue consistency by linking with modtestbed in inittimedepsv
l.60 in:
use modtestbed, only : ltestbed,ntnudge,&
tb_time
l.70 in:
if (ltestbed) then
kflux = ntnudge
kls = ntnudge
else
kflux = 10000
kls = 10000
end if
- remove incorrect MPI command
l.152 delete:
call MPI_BCAST(timesvz(1:kflux),kflux,MY_REAL,0,comm3d,mpierr)
Obukhov length calculation fails
I'm trying to run a simulation with zero-flux boundary conditions at the ground. This seems to be possible, by choosing flux boundary conditions (isurf=4) and setting the temperature and qt fluxes to 0. However, this causes the Obukhov length calculation to fail, before the first time step has been completed.
To reproduce:
Fresh clone of dales master branch, compiled in DEBUG mode.
cases/example
in namoptions.001, set wtsurf=0 and wqsurf=0.
isurf=4 is already set, meaning flux boundary conditions at the ground.
Running this results in:
.....
&NAMCAPE
LCAPE=F,
DTAV= 60.000000000000000 ,
/
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP Obukhov length calculation does not converge!
The stop occurs in subroutine getobl(), in modsurface.f90, line 1307 (i.e. the second convergence check).
The reason may be that on line 1280, Rib gets set to 0 since thv = thvs, which seems to happen when the boundary fluxes are set to 0.
The case Rib = 0 is then not handled in the if:s that follow on 1285, should it be?
gfortran warnings (3 occurrences): Type mismatch in argument 'ifac' (fftnew.f90)
dales/src/fftnew.f90:726.36:
call RFFTB1 (N,R,WSAVE,WSAVE(N+1),WSAVE(2*N+1))
1
Warning: Type mismatch in argument 'ifac' at (1); passed REAL(8) to INTEGER(4)
dales/src/fftnew.f90:804.36:
call RFFTF1 (N,R,WSAVE,WSAVE(N+1),WSAVE(2*N+1))
1
Warning: Type mismatch in argument 'ifac' at (1); passed REAL(8) to INTEGER(4)
dales/src/fftnew.f90:881.28:
call RFFTI1 (N,WSAVE(N+1),WSAVE(2*N+1))
1
Warning: Type mismatch in argument 'ifac' at (1); passed REAL(8) to INTEGER(4)
wrong values of xt,yt,... in cape and fieldoutput
Hi there,
I noticed that DALES still takes the variable myid to calculate the values of xt,yt,... in the cape and field outputs. I guess, myidx and myidy should be used instead.
The following changes in modstat_nc.f90 fixed this issue for me...
321c321
< use modglobal, only : dx,dy,zf,zh,jmax
---
> use modglobal, only : dx,dy,zf,zh,jmax,imax
323c323
< use modmpi, only : myid
---
> use modmpi, only : myid,myidx,myidy
329c329
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*(0.5+i),i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*(0.5+i)+myidx*imax*dx,i=0,length-1)/),(/1/))
332c332
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*i,i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*i+myidx*imax*dx,i=0,length-1)/),(/1/))
336c336
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*(0.5+i)+myid*jmax*dy,i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*(0.5+i)+myidy*jmax*dy,i=0,length-1)/),(/1/))
339c339
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*i+myid*jmax*dy,i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*i+myidy*jmax*dy,i=0,length-1)/),(/1/))
356c356
< use modglobal, only : dx,dy,zf,zh,jmax
---
> use modglobal, only : dx,dy,zf,zh,jmax,imax
358c358
< use modmpi, only : myid
---
> use modmpi, only : myid,myidx,myidy
364c364
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*(0.5+i),i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*(0.5+i)+myidx*imax*dx,i=0,length-1)/),(/1/))
367c367
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*i,i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dx*i+myidx*imax*dx,i=0,length-1)/),(/1/))
371c371
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*(0.5+i)+myid*jmax*dy,i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*(0.5+i)+myidy*jmax*dy,i=0,length-1)/),(/1/))
374c374
< if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*i+myid*jmax*dy,i=0,length-1)/),(/1/))
---
> if (iret==0) iret = nf90_put_var(ncid, varID, (/(dy*i+myidy*jmax*dy,i=0,length-1)/),(/1/))
Cheers
Subgrid turbulence scheme regression
Commit 2e6f725 "Fix of Arnold: Fixed division-by-zero error in SGS-TKE fix" causes some runs to crash. In particular, the arm_brown test case crashes immediately.
That commit makes a change to avoid a division by 0, in case the horizontal velocity is exactly 0 (i.e. both u = 0 and v = 0). It also removes a cap on local_dudz (and same for local_dvdz) further down:
if (abs(local_dudz) > abs(dudz(i,j))) then
local_dudz = dudz(i,j)
endif
It turns out this cap is needed when the subgrid-scale turbulence is low, i.e. ekm(i,j,1) is small.
This can happen either if the run is initialized with ekm = 0 at the surface as in the arm_brown case, or later in the run if low ekm from higher up in the atmosphere is advected down. A too large local_dudz will in turn cause instabilities later, by resulting in very large ekm.
I propose that this commit is reverted. Note that the horizontal velocity being exactly 0 is unlikely (for both components at once), and that tiny but non-zero velocities do not result in any problems.
Also, the cap seems dubious. In practice it is triggered also in what seems to be normal circumstances. local_dudz and dudz may even have different signs, and then the sign of local_dudz is changed for what seems to be no physical reason.
Adaptive time step constraints not stict enough
In tstep.f90, tstep_update() determines the largest dt that is safe to use.
In the model, there are two diffusion rates, ekm for momentum and ekh for other quantities (thl, qt). W.r.t. diffusion, the time step is currently limited only based on ekm. However, ekh is larger than ekm, and thus the time step limit is not always strict enough.
Some of our model crashes showed checkerboard-like disturbances in qt, of the kind that show up when a diffusion problem is solved with too large time steps. When I added ehk to the time step criterion, those problems disappeared.
peclettotl=max(peclettotl,maxval(ekm(2:i1,2:j1,k))*rdt/minval((/dzh(k),dx,dy/))**2)
peclettotl=max(peclettotl,maxval(ekh(2:i1,2:j1,k))*rdt/minval((/dzh(k),dx,dy/))**2) ! propose adding this
Note there are two places in the code where this should be done. This of course comes with the cost of smaller time steps, so the simulations take longer.
In another sense, the diffusion time step limit is sometimes too strict. It considers the smallest of (dx, dy, dz). When dz << dx, dy, this is stricter than necessary.
The current condition is
ekh * dt * (1/min(dx,dy,dz)**2) < 1/6
which could, I think, be relaxed to
ekh * dt * (1/dx**2 + 1/dy**2 + 1/dz**2) < 1/2
The constant 1/6 is actually the parameter peclet.
gfortran warnings (15 occurrences): Possible change of value in conversion from INTEGER(8) to INTEGER(4)
dales/src/modgenstat.f90:204.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modbudget.f90:113.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modbudget.f90:156.17:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modbulkmicrostat.f90:124.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modbulkmicrostat.f90:192.17:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modlsmstat.f90:98.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modlsmstat.f90:138.17:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modsimpleicestat.f90:124.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modsimpleicestat.f90:191.17:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modradstat.f90:118.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modradstat.f90:184.17:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modsampling.f90:216.17:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modsamptend.f90:170.17:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modstattend.f90:91.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
dales/src/modstattend.f90:134.15:
nsamples = itimeav/idtav
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1)
module initialization order - readinitfiles and microphysics
Commit 4f35105 in version 4.2.1 changes the initialization order to
call initmicrophysics
call readinitfiles
in modstartup.f90, line ~292.
This change breaks the simpleice2 microphysics, which needs rhobf profiles in its initialization routine to calculate some lookup tables.
If this order is necessary (why?), I can adapt the simpleice2 scheme, and calculate the lookup tables on each call - performance should not suffer much.
to2.4 branch: bomex case crashes, divide-by-0
Hi All,
I just noticed that the bomex case doesn't work in the to2.4 branch.
Default options, gnu compiler, debug build. Backtrace:
#3 0x82621a in solmpj
at /home/jansson/code/official-dales/src/modpois.f90:290 <---
#4 0x82905a in __modpois_MOD_poisson
at /home/jansson/code/official-dales/src/modpois.f90:98
#5 0xb5fdf1 in dales
at /home/jansson/code/official-dales/src/program.f90:253
#6 0xb5ff1e in main
at /home/jansson/code/official-dales/src/program.f90:103
This is the crashing line, in modpois.f90:290, where z was 0.
p(i,j,kmax) = (p(i,j,kmax)-ak*p(i,j,kmax-1))/z
z is calculated a few lines up, from these values:
z = bbk-ak*d(i,j,kmax-1)
bbk = -0.0005447011209443629
ak = 0.0005447011209443629
d() = -1
Other cases, like fog, rico, example are not affected. From bisection, it seems the crash starts occurring with the merge 60eceb4, but I don't know in which commit since I don't manage to compile these versions which use a different CMakeList.
base profile initialization fails with ibas_prf=3 and zf(k) = 11000
Running DALES with ibas_prf=3 (the default) causes undefined behaviour (often a thermo crash) if the model has a vertical level at exactly 11000 m.
modstartup.f90, line 1305, initializing the rhobf profile when ibas_prf = 3
real,dimension(4) :: zmat=(/11000.,20000.,32000.,47000./)
real,dimension(4) :: lapserate=(/-6.5/1000.,0.,1./1000,2.8/1000/)
...
do k=1,k1
if(zf(k)<zmat(1)) then
pb(k)=exp((log(ps)*lapserate(1)*rd+log(tsurf+zsurf*lapserate(1))*grav-&
log(tsurf+zf(k)*lapserate(1))*grav)/(lapserate(1)*rd))
tb(k)=tsurf+lapserate(1)*(zf(k)-zsurf)
else
j=1
do while(zf(k)>zmat(j)) !! bug here, ">" should be ">="
j=j+1
end do
tb(k)=tmat(j-1)+lapserate(j)*(zf(k)-zmat(j-1))
This code uses a table of temperature lapse rates lapserate(j) in different height intervals given by zmat(j) The problem occurs if any height level zf(k) equals zmat(1), which is defined as 11000. Then the else clause is run, the while loop is not executed, and j=1, which makes the final line access tmat(0) and zmat(0), which are undefined.
Fix: change the > sign in while() to >= , this ensures that after the while loop j is at least 2.
Finding netCDF in CMake
DALES CMakeLists.txt contains a hard-coded list of places to search for the netCDF library. On the Lisa cluster this currently gives me problems, as it picks up the system netCDF in /usr/lib/... regardless of whether or not I load a specific netCDF module. The library in /usr/lib is not guaranteed to be compatible with the other modules. For example, my final executable on Lisa ends up linking to both libgfortran 3 and 4.
Perhaps a better way to find netcdf would be the nf-config program. Loading modules on a cluster will put the correct nf-config in the path, so this way should respect modules. I propose replacing the netcdf finding by the following:
execute_process(COMMAND nf-config --flibs OUTPUT_VARIABLE NETCDF_FORTRAN_LIB OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND nf-config --includedir OUTPUT_VARIABLE NETCDF_INCLUDE_DIR OUTPUT_STRIP_TRAILING_WHITESPACE)
Possibly a manual way to supply the paths should be added as well - we want this in the OMUSE interface where we rely on AMUSE's configure to find netCDF.
One issue with this is that nf-config is broken on Fedora by not supplying a path to the module file.
bug in advec_52 and advec_5th
There is a typo in advec_52.f90 and advec_5th.f90, in the advecv routines.
- -sign(1.,(v0(i,j+1,k)+v0(i,j,k)))*(v0(i,j+1,k)+v0(i,j+1,k))/60.&
+ -sign(1.,(v0(i,j+1,k)+v0(i,j,k)))*(v0(i,j+1,k)+v0(i,j,k))/60.&
The sign(1,x)*x construction is for calculating abs(x). In this particular place, the final term has j+1 where it should be j. This line is present twice in each of the files advec_52.f90 and advec_5th.f90. In advec_5th, only the top and bottom boundaries are affected, not the bulk.
I plan to replace the sign() constructions by abs() for readability. I will patch this expression first as a separate commit, as documentation of why the results change.
Time interpolation and indexing in modtimedep
From Yi Dai and Stephan de Roode: a problem in modtimedep.
In the current master version we have
if(.not.(ltimedepsurf)) return
! --- interpolate! ----
t=1
do while(rtimee>timeflux(t))
t=t+1
end do
if (rtimee>timeflux(t)) then !!!! stephan: this has changes in the new version
t=t-1
endif
In the previous version we have
if(.not.(ltimedepsurf)) return
! --- interpolate! ----
t=1
do while(rtimee>timeflux(t))
t=t+1
end do
if (rtimee/=timeflux(t)) then !!! stephan: this is the original (working) version
t=t-1
endif
The current version gives wrong results for the last time block of time-dependent input values.
The change was introduced in commit e3c1ec8 to avoid == comparisons of floats. I propose the change is reverted, or the code rewritten more nicely:
do while(rtimee>timeflux(t+1))
t=t+1
end do
! desired condition for the interpolation:
! timeflux(t) <= rtimee <= timeflux(t+1)
! we want the smallest t, for which timeflux(t+1) >= rtime
There is a similar construction in the routine timedepz which should be reverted also.
Simpleice microphysics does not use Nc_0 from Namoptions
...instead modsimpleice uses particle densities specified in modmicrodata.f90, separately for rain, snow and graupel: n0rr=2.e7, n0rs=2.e7, n0rg=2.e7.
This should be mentioned in the namoptions documentation, as one easily thinks Nc_0 in the namoptions applies to all microphysics schemes. (Alternatively, these parameters could be read from Namoptions too).
RRTMG: timedependent albedo routine called only on setup
When using RRTMG with lCnstAlbedo = .false., a solar-angle-dependent parameterization of albedo is used.
Line 846 in 0d7e912
This function is called only on initialization, it should be called more often since the zenith angle is time-dependent.
Specifically, if initializing at night, the albedo is 0.
Why the option "NAMSIMPLEICESTAT" doesn't work?
Hi,everyone! I use the microphysical scheme (5 = Simple ice microphysics) in dales. However, when I want to output simple ice microphysics statistics calculation, the option "NAMSIMPLEICESTAT" doesn't work. I can't find the output results. I don't know why, anyone can help me? Thank you very much.
Best regards wangyinjun
refactor icethermo0 and icethermoh
I have refactored the routines icethermo0 and icethermoh in modthermodynamics.f90:
- a separate function for determining qsatur - this was inlined in the Newton's method code and hard to read
- added some comments
- added comments and a reference in modglobal.f90, where the saturation tables are calculated
Would you like to merge this? The commit is here: CloudResolvingClimateModeling@53c38ca
Testing:
I compared the prognostic fields after 1000s of simulation (cases/example) with and without this change, the sum(difference**2) was < 1e-8 for all of them. Is there some official testing procedure?
This should be possible to merge into the Dales master branch. I didn't make a real pull request, since that would include all previous commits in our branch as well. I can create a new branch and make a real pull request - which dales branch should I base it on then?
netCDF sync
With the switch to netCDF v4 in DALES 4.2 one drawback appears: the netCDF output files are not readable while the simulation is running, and may not be readable if the run crashed or was interrupted. Reported by Kevin Helfer.
Suggestion
add NF90_SYNC(ncid) calls:
- when writing a restart file
- at configurable intervals during the simulation
Workarounds
switch back to netCDF v3 by replacing the netCDF creation call
- iret = nf90_create(fname,NF90_NETCDF4,ncid)
+ iret = nf90_create(fname,NF90_SHARE,ncid)
Or add sync calls as in 2e5b07a where the interval is not yet configurable, overhead of this still unknown.
modradfull: subroutine interpolate defined but not used
dales/src/modradfull.f90:2061:0: warning: ‘interpolate’ defined but not used [-Wunused-function]
subroutine interpolate(x,ny,y,i1,i2,alpha)
Simpleice(2) microphysics and negative qt
The simpleice scheme can cause negative qt, perhaps in combination with advection, even when a positive advection scheme is used. The simpleice schemes have a guard against making qr negative, but not against making qt negative.
Suggestion: cap the tendencies generated in microphysics so that qt doesn't become negative.
The qt considered for the test should already include the contribution from advection.
Complication: qt tendencies are accompanied with thl tendencies, which should be adjusted as well.
BUG: lhetero = .true. uses incorrect values for thls and rssoilmin
With lhetero = .true. in NAMSURFACE, two surface variables are incorrectly initialized in modsurface.f90: thls and rssoilmin.
This leads to significantly different outcomes for two runs which only differ in the lhetero swich (.true./.false.) for isurf = 1.
modsurface.f90, line 442:
thls = 300
This overwrites the thls specified in namoptions PHYSICS.
modsurface.f90, line 1580:
rssoilmin (i,j) = rsmin_patch (tempx,tempy)
Here, rssoilmin is set equal to rsmin.
With the help of Bart, we solved the issues by removing line 442 and by adding a new input field for rssoilmin in the input file surface.interactive.inp.xxx. With these two corrections, the aforementioned two runs produce near identical results.
Below, I added my corrected versions of modsurface.f90 and modsurfdata.f90 as .txt files
modsurface.f90.txt
modsurfdata.f90.txt
gfortran warnings (31 occurrences): Possible change of value in conversion from REAL(8) to INTEGER(8)
dales/src/modglobal.f90:452.19:
tnextrestart = trestart/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modgenstat.f90:199.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modgenstat.f90:200.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modbudget.f90:108.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modbudget.f90:109.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modbulkmicrostat.f90:119.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modbulkmicrostat.f90:120.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modcape.f90:76.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modchecksim.f90:37.34:
integer(kind=longint) :: tnext = 3600.,itcheck
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modtimestat.f90:118.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modchem.f90:261.15:
idtchmovie = dtchmovie/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modcloudfield.f90:71.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modcrosssection.f90:117.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modfielddump.f90:83.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modheterostats.f90:109.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modlsmcrosssection.f90:104.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modlsmstat.f90:93.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modlsmstat.f90:94.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modsimpleicestat.f90:119.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modsimpleicestat.f90:120.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modradstat.f90:113.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modradstat.f90:114.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modsampling.f90:135.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modsampling.f90:136.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modsamptend.f90:107.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modsamptend.f90:108.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modprojection.f90:97.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modstattend.f90:86.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modstattend.f90:87.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modstattend.f90:129.12:
idtav = dtav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
dales/src/modstattend.f90:130.14:
itimeav = timeav/tres
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(8) at (1)
GOAMAZON14 case does not run
WARNING ::: There is no CO2 defined in the chemistry scheme
WARNING ::: Scalar 1 might be considered to be CO2
STOP ERROR: Problem in namoptions NAMSURFACE - AGS
printed at line 1822 in modsurface.f90.
This is with the branch to4.3_Fredrik, where the chemistry and surface code is unchanged since Dales 4.2.1.
Scalar 21 is CO2 according to chem.inp.047 and scalar.inp.047.
Units of output of budget routines (related to multiplication with density)
Dear all,
Not a major issue, but rather a cause of confusion. In the computation of budget terms at each timestep each term (as well as the total TKE and SFS TKE) is multiplied with the appropriate density. This multiplication is, as far as I can see, related to the introduction of the anelastic approximation.
However, after the computation of the mean, at the end of the averaging period, the density is not divided out. This implies that the units of the terms stored in the output files are not m^2/s^3 but kg/m^-1/s^3 (NB: the units given now in the NetCDF are wrong anyway: m/s^2).
The question is: is the solution simply a matter of dividing the current output by a the temporal and spatial mean rhobh(k)? Or is there more to it?
Best, Arnold
Line 158 in ff38f8d
Combination of lwarmstart = .true. and iadv_(qt/thl) = 7 causes crash
In modstartup.f90in subroutine startup:
else !if lwarmstart
call readrestartfiles
...
call calc_halflev
...
call baseprofs !call baseprofs
end if ! end if (.not. warmstart)If iadv_(qt/thl) = 7 (Kappa Advection scheme) calc_halflev calls halflev_kappa from advec_kappa.f90
In halflev_kappa we divide by rhobh which is set to 0 before being read in in baseprofs only after the half-level calculation. The calculated NaN-value then happily propagates through the code and causes a segementation fault down the line.
I am now checking if the easy fix is just to put call baseprofs before call calc_halflev.
wa1 array reference out of bounds
After updating to the new master branch (from 4.0) I get this error...
Fortran runtime error: Array reference out of bounds for array 'wa1', upper bound of dimension 1 exceeded (2 > 1)
At line 418 of file ../dales-master/src/fftnew.f90
At line 418 of file ../dales-master/src/fftnew.f90
Backtrace for this error:
+ function radf3_ (0x4BA4A0)
at line 418 of file fftnew.f90
+ function rfftf1_ (0x4CBEA8)
at line 823 of file fftnew.f90
+ function rfftf_ (0x4CB669)
at line 806 of file fftnew.f90
+ function __modfft2d_MOD_fft2df (0xA2CB16)
at line 335 of file modfft2d.f90
+ function __modpois_MOD_solmpj (0x894295)
at line 249 of file modpois.f90
+ function __modpois_MOD_poisson (0x89977F)
at line 99 of file modpois.f90
+ in the main program
at line 250 of file program.f90
+ /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f56c5f55c5d]
Simpleice microphysics - parameters differ from cited references
In modsimpleice.f90, subroutine evapdep, the coefficients for the ventilation factor for snow differs from the values in the references.
ventr=.78*n0rr/lambdar(i,j,k)**2 + gam2dr*.27*n0rr*sqrt(ccrz(k)/2.e-5)*lambdar(i,j,k)**(-2.5-0.5*ddr)
vents=.78*n0rs/lambdas(i,j,k)**2 + gam2ds*.27*n0rs*sqrt(ccsz(k)/2.e-5)*lambdas(i,j,k)**(-2.5-0.5*dds)
ventg=.78*n0rg/lambdag(i,j,k)**2 + gam2dg*.27*n0rg*sqrt(ccgz(k)/2.e-5)*lambdag(i,j,k)**(-2.5-0.5*ddg)
For rain and graupel, the values match the references. For snow, 0.78 -> 0.65, and 0.27 -> 0.39, according to Grabowski 1998 and
Tomita 2008.
gfortran warning: Change of value in conversion from REAL(16) to REAL(8)
dales/src/modglobal.f90:578.47:
eps = 2.22D-16, xinf = 1.79D308
1
Warning: Change of value in conversion from REAL(16) to REAL(8) at (1)
NetCDF error if `genstat` is set to `.false.` in `arm_brown` case
If the statistics are switched off in the arm_brown case, the model crashes with a NetCDF id error immediately.
Large scale `thl` tendencies not applied with radiation on.
The time varying thl tendencies (modtimedep.f90) are read into thlpcart, which is averaged in time into thlpcar, which is applied as a radiative tendency in modradiation.f90, but only when rad_ls=.true.. But with radiation on, e.g. for iradiation=4, rad_ls is set to .false.:
case (4)
iradiation = 2
rad_ls = .false.
rad_longw = .true.
rad_shortw = .true.
rad_smoke = .false.
I see two possible solutions: (1) read the thl tendencies in modtimedep.f90 into dthldtlst (like is done with ltestbed=.true.), which is applied as a tendency in modforces.f90, or always set rad_ls to .true.. I think I would prefer (1); then the thl tendency can be seen as a large scale advective tendency, a radiative tendency, or both.
gfortran warning: Possible change of value in conversion from INTEGER(4) to INTEGER(2)
dales/src/modchem.f90:454.15:
number = number + 1
1
Warning: Possible change of value in conversion from INTEGER(4) to INTEGER(2) at (1)
gfortran warnings (17 occerrences): Possible change of value in conversion from REAL(16) to REAL(8)
dales/src/modglobal.f90:583.31:
REAL (dp), PARAMETER :: P(8) = &
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modglobal.f90:588.31:
REAL (dp), PARAMETER :: Q(8) = &
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modglobal.f90:596.31:
REAL (dp), PARAMETER :: c(7) = &
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modpois.f90:79.14:
rk3coef = rdt / (4. - dble(rk3step))
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modradfull.f90:1260.24:
randomNumber = getRandomReal(randoms)
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modradfull.f90:1140.22:
randomNumber = getRandomReal(randoms)
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modsurface.f90:1668.18:
rk3coef = rdt / (4. - dble(rk3step))
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modbulkmicro.f90:151.11:
delt = rdt/ (4. - dble(rk3step))
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modsimpleice.f90:113.11:
delt = rdt/ (4. - dble(rk3step))
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/modsamptend.f90:458.20:
lastrk3coef = rdt / (4. - dble(rk3step))
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/tstep.f90:91.14:
rdt = dble(dt)*tres
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/tstep.f90:94.18:
rtimee = dble(timee)*tres
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/tstep.f90:104.14:
rdt = dble(dt)*tres
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/tstep.f90:124.14:
rdt = dble(dt)*tres
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/tstep.f90:128.18:
rtimee = dble(timee)*tres
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/tstep.f90:137.18:
rtimee = dble(timee)*tres
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
dales/src/tstep.f90:174.12:
rk3coef = rdt / (4. - dble(rk3step))
1
Warning: Possible change of value in conversion from REAL(16) to REAL(8) at (1)
gfortran warnings (8 occurrences): Possible change of value in conversion from REAL(8) to REAL(4)
dales/src/modchem.f90:2151.17:
dummy(:,:,:)=svm(2:i1,2:j1,1:kmax,n)
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
dales/src/modchem.f90:2159.19:
dummy(:,:,:) = svm(2:i1,2:j1,1:kmax,n) - ybegin(2:i1,2:j1,1:kmax,n)
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
dales/src/modchem.f90:2183.17:
dummy(:,:,:) = qt0(2:i1,2:j1,1:kmax)
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
dales/src/modchem.f90:2189.17:
dummy(:,:,:) = ql0(2:i1,2:j1,1:kmax)
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
dales/src/modchem.f90:1671.24:
k3d(:,:,k,tnor+1) = T_abs
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
dales/src/modchem.f90:1672.24:
k3d(:,:,k,tnor+2) = convppb
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
dales/src/modchem.f90:1691.23:
k3d(:,:,k,i) = keff(:,:,RC(i)%Kindex,k)
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
dales/src/modchem.f90:1735.23:
k3d(:,:,k,i) = keffT(:,:,RC(i)%Kindex)
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
5 "may be used uninitialized" gfortran warnings in modtimestat.f90
dales/src/modtimestat.f90:1065:0: warning: ‘blh_fld2.dim[2].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized]
profile = blh_fld2(i,j,:)
dales/src/modtimestat.f90:943:0: warning: ‘blh_fld2.dim[2].stride’ may be used uninitialized in this function [-Wmaybe-uninitialized]
real, allocatable,dimension(:,:,:) :: blh_fld, sv0h, blh_fld2
dales/src/modtimestat.f90:943:0: warning: ‘blh_fld2.dim[1].stride’ may be used uninitialized in this function [-Wmaybe-uninitialized]
dales/src/modtimestat.f90:1083:0: warning: ‘blh_fld2.offset’ may be used uninitialized in this function [-Wmaybe-uninitialized]
blh_fld2(i1,2:j1,:) = blh_fld(i1-1,2:j1,:) + blh_fld(i1,2:j1,:) + blh_fld(2,2:j1,:)
dales/src/modtimestat.f90:367:0: warning: ‘patchy’ may be used uninitialized in this function [-Wmaybe-uninitialized]
full radiation documentation?
The documentation of the input files for full radiation scheme seems to be missing, making it difficult to edit them.
The modradfull takes a few input files (ckd.inp., backrad.inp., cldwtr.inp.*), however neither of them are in the format that would be self descriptive. Specifically, "ckd.inp.*" describes absorption bands for different gases, however neither it appears that neither units nor altitude data are described.
I have also checked the source materials on full radiation scheme ([https://doi.org/10.3894/JAMES.2009.1.1] ,
[https://doi.org/10.1175/1520-0469(1997)054<2799:MSPITI>2.0.CO;2]) without success.
Please, does any of you know where to find the input file description?
netcdf output (cross-sections etc) and restarts
NetCDF output, at least cross sections, from runs that have been restarted, seem to miss one field at the time of the restart. This seems to happen only when the original run went on past the time the restart tile was written.
Needs testing to verify. So far, I've seen it only for cross sections. Suspect off-by-one bug in the code opening an existing netCDF, and deciding on which index to continue writing.
gfortran warnings (3 occurrences): Nonconforming tab character
dales/src/modraddata.f90:59.15:
real :: SSA = 0.999 !< typical single scattering albedo for clouds
1
Warning: Nonconforming tab character at (1)
dales/src/modradstat.f90:244.17:
swdifav = 0.
1
Warning: Nonconforming tab character at (1)
dales/src/modradstat.f90:269.43:
swdifmn = swdifmn + swdifav/rslabs
1
Warning: Nonconforming tab character at (1)
compiler flags: -malign=double not working on ARM mac
On the new macs with M1 CPU, gfortran 11.1 does not support the -malign=double flag - probably it is for x86 only.
SYST=gnu-fast currently enables this flag.
Options:
- drop the flag (having the flag has some performance benefits on x86 according to Jisk)
- add another SYST flag for M1 systems (tedious to maintain)
- add the flag only if the system supports it (requires some CMake scripting)
Workaround: edit it out of the CMakeLists.txt file.
the constant-in-time base-state densities "rhobf" and "rhobh" are created as time-dependent vars in the output netCDF file
Here's the relevant part of ncdump output:
netcdf profiles.001 {
dimensions:
time = UNLIMITED ; // (6 currently)
zt = 80 ;
zm = 80 ;
variables:
float rhobf(time, zt) ;
rhobf:longname = "Full level density" ;
rhobf:units = "kg/m^3" ;
rhobf:_FillValue = -999.f ;
float rhobh(time, zm) ;
rhobh:longname = "Half level density" ;
rhobh:units = "kg/m^3" ;
rhobh:_FillValue = -999.f ;
gfortran warning: Possible change of value in conversion from REAL(8) to INTEGER(4)
dales/src/modthermodynamics.f90:433.20:
niter = 0.0
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at (1)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.