-
Notifications
You must be signed in to change notification settings - Fork 55
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
Several issues in modlsm.f90 #85
Comments
That is strange. For what kind of grids is it happening? |
I found that if simulation is warm start (starts from restart files), phiw(i,j,k) might turns into negative values for some grid points. This problem appears not at the beginning of the simulation but after about 10 hours, so it is probably resulted from some calculating issues before the crash. I used a large domain in that simulation itot = 1536, jtot = 768, dx = 156.25, dy = 156.25, for smaller domains, I did not see the same problem. Restart files are not corrupted and phiw(i,j,k) is correct at the simulation start. I did not dig deeper, just put the if statement and substitute all negative values to reasonable ones. May problems with advection somehow cause wrong values here? I found that advection scheme may cause some problems with CO2 values (too low at some grid points) that why I shifted to kappa advection scheme and problem was solved. |
with
here I'm currently getting crashes near the surface caused by a too high temperature. This may or may not be related to these LSM issues. Point 3 is a separate issue in my opinion. From the point of view of the DALES core, scalars such as CO2 are just advected around. You can give them any unit you want, but it has to be consistent in the different schemes that use the same scalar. |
Yes, I think that limiting |
@jchylik I only found this issue now, so my response is a bit late. We added a new land-surface model in the last few years, which more closely follows (C)HTESSEL, and allows for realistic land-use. I guess that you were still using the old one? |
@fjansson thanks for this suggestion, I will try to implement it. About issue 3, what I found is that the model crashed with seg fault right at the first-time step before calculation of tile_xx%rs. As I found, It is resulted from NaNs in tskin. Interestingly, the crash doesn't occur when I run the debug compiled code (cmake .. -DCMAKE_BUILD_TYPE="DEBUG") only at normal and fast run NaNs are appeared. So, tskin is somehow sensitive to the compilation type. In addition, tskin is not sensitive to the isnan function (isnan(tskin(i,j))), so in my code, I use this approach to exclude NaNs value (I printed tskin here and the value of 287K seems an average value of tskin ): (I used a copy to not change the original tskin) ! Check if tskin_copy (i, j) is less than 200 or more than 350, and replace with 287. I do not know, if NaNs in tskin are appeared everywhere or only in the subroutine Calc_canopy_resistance_ags, good to check. About units of CO2 tracer, here could be some inconsistency with others, since Marko implemented GHG scalar tracers in ug/g unit, whereas in the A-Gs scheme, it is seem assumed that the unit of co2 input is in ppb. |
Hello,
Here, I would like to describe several issues I revealed in the LSM module modlsm.f90 and my tentative suggestions to solve them. Note that each of them results in a segmentation fault:
Probably, some of these problems are happen in some grid points only, so they are domain-specific. Also, some of these issues may be interconnected, so resolving one of them could potentially address several others. In my case, I faced with them when simulating a fine domain:
My temporal solution was just to set the soil moisture content to 0 in the first place where it is used, if it turns into negative value, i.e., in subroutine calc_theta_mean(tile):
However, it needs to be checked more precisely.
theta_norm** (1. / vg_m)
becomes greater than 1, resulting in a rising of negative value to a fraction power in pure functioncalc_diffusivity_vg
and pure functioncalc_conductivity_vg: (1. - theta_norm ** (1. / vg_m))
.Here, I replace
theta_norm** (1. / vg_m)
with 0.9 everytime whentheta_norm** (1. / vg_m)>1
. However, it should be fixed in a more prompt way, I guess:Let me know, if I was not right somewhere and if you have a more smart way to solve issues I mentioned.
Cheers,
Arseni
Edits by Fredrik: added code tags
The text was updated successfully, but these errors were encountered: