Coder Social home page Coder Social logo

noahmp's Introduction

noahmp_logo_update

DOI

Noah-MP® Community Model Repository

Noah-MP® is a widely-used state-of-the-art land surface model used in many research and operational weather/climate models (e.g., HRLDAS, WRF, MPAS, WRF-Hydro/NWM, NOAA/UFS, NASA/LIS, etc.).

This is the official Noah-MP land surface model unified repository for code downloading and contribution. Noah-MP is a community open-source model developed with the contributions from the entire scientific community. For development, maintenance, and release of the community Noah-MP GitHub code, please contact: Cenlin He ([email protected]) and Fei Chen ([email protected]).

Noah-MP model website: https://ral.ucar.edu/solutions/products/noah-multiparameterization-land-surface-model-noah-mp-lsm

New: Release of Noah-MP version 5.0 (Refactored/Modernized version)

The latest Noah-MP model version (version 5.0) has been released in March 9, 2023, which is a modernized/refactored version by re-writing the entire model with modern Fortran code infrastructure and data structures. All future Noah-MP developments and updates will be made only to this modernized/refactored version. The version 5.0 has the same model physics as the version 4.5, but with a different code infrastructure. More details about the Noah-MP version 5.0 can be found in the model description paper (He et al., 2023b, in review) and the technical documentation (He et al. 2023a). Currently, the Noah-MP version 5.0 coupling with HRLDAS has been completed, but its coupling with other host models (e.g., WRF-Hydro, NASA/LIS, WRF, MPAS, UFS, etc.) is still on-going.

Noah-MP technical documentation and model description papers

Technical documentation freely available at http://dx.doi.org/10.5065/ew8g-yr95

To cite the technical documentation: He, C., P. Valayamkunnath, M. Barlage, F. Chen, D. Gochis, R. Cabell, T. Schneider, R. Rasmussen, G.-Y. Niu, Z.-L. Yang, D. Niyogi, and M. Ek (2023): The Community Noah-MP Land Surface Modeling System Technical Description Version 5.0, (No. NCAR/TN-575+STR). doi:10.5065/ew8g-yr95

Original Noah-MP model description paper: Niu, G. Y., Yang, Z. L., Mitchell, K. E., Chen, F., Ek, M. B., Barlage, M., ... & Xia, Y. (2011). The community Noah land surface model with multiparameterization options (Noah‐MP): 1. Model description and evaluation with local‐scale measurements. Journal of Geophysical Research: Atmospheres, 116(D12).

Noah-MP version 5.0 model description paper: He, C., Valayamkunnath, P., Barlage, M., Chen, F., Gochis, D., Cabell, R., Schneider, T., Rasmussen, R., Niu, G.-Y., Yang, Z.-L., Niyogi, D., and Ek, M.: Modernizing the open-source community Noah with multi-parameterization options (Noah-MP) land surface model (version 5.0) with enhanced modularity, interoperability, and applicability, Geosci. Model Dev., 16, 5131–5151, https://doi.org/10.5194/gmd-16-5131-2023, 2023.

Noah-MP development future priority paper: He, C., Chen, F., Barlage, M., Yang, Z.-L., Wegiel, J. W., Niu, G.-Y., Gochis, D., Mocko, D. M., Abolafia-Rosenzweig, R., Zhang, Z., Lin, T.-S., Valayamkunnath, P., Ek, M., and Niyogi, D. (2023): Enhancing the community Noah-MP land model capabilities for Earth sciences and applications, Bull. Amer. Meteor. Soc., E2023–E2029, https://doi.org/10.1175/BAMS-D-23-0249.1

Noah-MP GitHub structure

The folders:

  1. docs/: Noah-MP variable glossary and technical documentation;

  2. drivers/: Noah-MP driver and interface code to connect to different host models (each host model will has its own subdirectory under this driver/);

  3. parameters/: Noah-MP parameter table (note that the original 3 parameter tables have been merged into one NoahmpTable.TBL starting from version 5.0);

  4. src/: Noah-MP source code modules;

  5. utility/: Noah-MP utility code.

The branches:

  1. "master" branch: (currently version 5.0), most stable & latest version, updated whenever there are bug fixes or major model update/release (by merging from the "develop" branch);

  2. "develop" branch: (currently version 5.0), used for continuous NoahMP development, keep updated by including bug fixes and code updates (e.g., new physics options, processes, etc.);

  3. other version release branches: store different released code versions.

Important notes

This GitHub repository only provides the Noah-MP source code and driver/interface code. To run Noah-MP in either offline or online mode, users need to have the host model system/framework coupled with Noah-MP.

NCAR also maintains and releases the HRLDAS (High Resolution Land Data Assimilation System) coupled with Noah-MP to allow offline Noah-MP simulations. Please see the HRLDAS GitHub repository (https://github.com/NCAR/hrldas) for details. For users who are interested in other host models that couple with Noah-MP, please refer to those host model GitHub repositories.

For users who are interested in previous Noah-MP code versions (prior to version 5.0), please refer to the different GitHub branches in this repository. Particularly, the "release-v4.5-WRF" branch has the same model physics as the Noah-MP version 5.0, but with an old model code structures, which is consistent with the Noah-MP code released along with WRF version 4.5.

Code contribution via GitHub

Users are welcome to make code development and contributions through GitHub pull requests. The pull request will be reviewed by the Noah-MP model physics and code release team, and if everything looks good, the pull request of new code development or bug fixes will be merged into the develop branch. During each year's major version release period, the updated develop branch will be further merged into the master branch for official release of a new Noah-MP model version.

Some suggestions for model developers to contribute to Noah-MP code through the GitHub repository (typical procedures):

  1. Step (1) Create a fork of this official Noah-MP repository to your own GitHub account;

  2. Step (2) Create a new branch based on the latest "develop" branch and make code updates/changes in the forked repository under your own account;

  3. Step (3) Finalize and test the code updates you make;

  4. Step (4) Submit a pull request for your code updates from your own forked Github repository to the "develop" branch of this official Noah-MP repository;

  5. Step (5) The Noah-MP physics and code review committee reviews and tests the model updates in the submitted pull request and discusses with the developer if there is any problem;

  6. Step (6) The Noah-MP physics and code review committee confirms the pull request and merges the updated code to the "develop" branch in this official Noah-MP repository;

  7. Step (7) The Noah-MP physics and code review committee merges the updated "develop" branch to the master branch during the annual release of new model versions.

License

The license and terms of use for this software can be found here

noahmp's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

noahmp's Issues

canopy heat storage not scaled by vegetation fraction

when calculating canopy heat storage term in vegetation flux iteration, the term should be scaled by vegetation fraction to be consistent with the radiation scaling in the solution:

HeatCapacCan = HeatCapacCanFac*VegAreaIndTmp*ConstHeatCapacWater + CanopyLiqWater*ConstHeatCapacWater/ConstDensityWater + &

For example, when the term is not scaled, the vegetation temperature will depend on vegetation fraction:

without canopy heat scaling, fveg = 0.1: tv = 310.48472113867035
without canopy heat scaling, fveg = 0.9: tv = 309.36242868601590

with canopy heat scaling, fveg = 0.1: tv = 309.27431763431838
with canopy heat scaling, fveg = 0.9: tv = 309.27431763431838

Crop option=1 issue for planting, harvesting, etc.

In the current Noah-MP, when crop option = 1, the parameters like planting date, harvesting date, and GDD are first assigned with the values from the NoahmpTABLE.TBL parameters:
https://github.com/NCAR/noahmp/blob/master/drivers/hrldas/BiochemVarInTransferMod.F90#L80
However, these parameters are then replaced by the variables from the crop static input file:
https://github.com/NCAR/noahmp/blob/master/drivers/hrldas/BiochemVarInTransferMod.F90#L125
So this makes the calibrated NoahmpTABLE.TBL table values for those parameters not used. Everytime, users want to calibrate these parameters, they have to change the input file values. Is this something designed by purpose initially or is this a bug? I also checked the version before v5.0, they have the same treatment.

SNEQV depleting but not being accounted for in simulations

I have been running Noah-MP in offline mode using ERA5 as a forcing for some model development, and I came across and issue that I wanted to bring to your attention. In the snow module COMBINE, there is an if else statement that uses the following call:
IF (ISNOW_OLD < -1) THEN (around ~7000 in module_sf_noamplsm.F)

This was causing an issue, when snow jumped more then one level (in my case going from a 2 snow layers to no snow layers) the loop would not account for the loss of snow water equivalent, and then trigger the ERROR module for water balances.

I seem to have fixed this by taking the advice of the comment from MB/KM and change the if else statement to be
IF (ISNOW < -1) THEN

  1. Is this a physically feasible correction to implement? and if so 2) I wanted to bring this to your attention!

Index out of bound for Urban LCZ cases in conversion of lfmass

If urban with LCZ is selected IVGTYP ranges from 1-61. SLA_TABLE is however only defined up to 20/27 depending on the landuse dataset selected. This leads to reading beyond the bounds of SLA_TABLE.

             masslai = 1000. / max(SLA_TABLE(IVGTYP(I,J)),1.0)

https://github.com/NCAR/noahmp/blob/981d4f859ce6c64213d38a783654c05b47b3485e/drivers/wrf/module_sf_noahmpdrv.F#L2184C14-L2184C101

Maybe something like this can solve the issue:

if(urbanpt_flag)  then
   masslai = 1000. / max(SLA_TABLE(NATURAL_TABLE),1.0)
else 
   masslai = 1000. / max(SLA_TABLE(IVGTYP(I,J)),1.0)
endif

negative theta_1500 in PedoTransferSR2006Mod.F90

The pedotransfer function calculates the negative theta_1500, so the model has floating invalid issue using log function at calculating the BEXP

bexp = 3.816712826 / (log(theta_33) - log(theta_1500) )

See below example,
sand: 0.7781111
clay: 7.7999993E-03
theta_1500: -1.1482276E-03

adding the following two constraints

theta_33    = max(10.0**-5.0,theta_33)  ! For numerical stability
theta_1500  = max(10.0**-5.0,theta_1500)  ! For numerical stability

before

! assign property values

can revolve

Compiling error EnergyVarInitMod.f90:25.4: associate( & 1 Error: Unclassifiable statement at (1)

Hello. I am trying to install the newest hrldas/Noahmp and i meet this compiling error:

mpif90-c -I. -I../utility -I../drivers/hrldas -g -fconvert=big-endian -fbounds-check  -fno-range-check  -ffree-form -ffree-line-length-none  -I/public/software/intel/netcdf4/include/ EnergyVarInitMod.f90
EnergyVarInitMod.f90:25.4:

    associate(                                                         &
    1
Error: Unclassifiable statement at (1)
EnergyVarInitMod.f90:394.7:

    end associate
       1
Error: Expecting END SUBROUTINE statement at (1)
EnergyVarInitMod.f90:164.73:

       allocate( noahmp%energy%state%TemperatureSoilSnow(-NumSnowLayerMax+1:Num

It seems likes the error comes from the associate subroutine, this is a new subroutine in fortran 2003. So I guess that the reason is the compiler in the super computer is too old, but I am not sure.
The compiler is :

1) compiler/intel/intel-compiler-2017.5.239
2) mpi/intelmpi/5.0.2.044

user_option:


#=============================================================================================
#  Options for Linux with Intel Fortran MPI
#=============================================================================================

 COMPILERF90    =       mpif90
 MPPFLAG        =       YES
 FREESOURCE     =       -ffree-form -ffree-line-length-none
 F90FLAGS       =       -g -fconvert=big-endian -fbounds-check  -fno-range-check # -fno-underscoring
 MODFLAG        =       -I ../MPP
HYDRO_LIB      =       ../MPP/mpp_land.o ../MPP/CPL_WRF.o
 LDFLAGS        =
 CPP            =       cpp
 CPPFLAGS       =       -P -traditional -DMPP_LAND # -DSPATIAL_SOIL
 LIBS           =
 LIBJASPER      =      -L/public/home/zhangzilu/Build_WRF/LIBRARIES/grib2/lib/ -ljasper
 INCJASPER      =      -I/public/home/zhangzilu/Build_WRF/LIBRARIES/grib2/include/
 NETCDFMOD      =      -I/public/software/intel/netcdf4/include/
NETCDFLIB      =      -L/public/software/intel/netcdf4/lib/ -lnetcdf -lnetcdff
 BZIP2          =       NO
# BZIP2_INCLUDE  =       -I/usr/include
# BZIP2_LIB      =       -L/usr/lib64 -lbz2
 RM             =       rm -f
 CC             =       cc

Is there any problem ? Thanks

Xiananjiang or Xinanjiang ?

There is a very small mistake in line 117 from src/module_sf_noahmplsm.F.
! 7 -> Xiananjiang Infiltration and surface runoff scheme ((Jayawardena and Zhou, 2000)
Perhaps Xinanjiang is right.

Also, in WRF and WRF User guide,This small mistake may also need to be corrected.
Thanks!

missing values in SMCWTD in the outermost grids after GROUNDWATER_INIT

Hello Cenlin, I think I found the issue for water balance issue for offline hrldas with mmf.
In the groundwater_init subroutine, the code is trying to initialize groundwater fields, especially SMCWTD.
The reference line shows the end of i,j loop and it excludes the outermost grids (ide-1), (jde-1). So after running groundwater_init, the SMCWTD has the missing values (9.9E36) at the outermost grids.

itf=min0(ite,ide-1)

I did a quick fix (just use ide, instead of ide-1), and the model can run without water balance issue.
This fix seems to work for offline hrldas, though I am not sure if it will cause problems in WRF code.

An error always occurs when running the model.

When running the model globally with GLDAS data, I always encounter the problem of 'forrtl: severe (174): SIGSEGV, segmentation fault occurred'. I have tried many methods but still do not know how to solve it. The specific error information is shown in the picture.
bug

Has anyone encountered this problem before or knows how to solve it?

wet canopy fraction is incorrectly a function of vegetation fraction

The partitioning of precipitation in precip_heat/CanopyWaterIntercept is scaled by fveg/VegFrac early in the module, but maxliq/CanopyLiqWaterMax (and similar for snow) are not scaled by fveg/VegFrac. This causes a dependence of fwet/CanopyWetFrac on vegetation fraction. I see two possible solutions:

  1. the easy one is to scale capacity by vegetation fraction (I have tested this and it does solve the issue)
  2. multiply by vegetation fraction later when water is input to the soil

I like solution 2 better since it is clearer to understand and the canopy water would be a physical value that is actually on the leaf and not spread across the grid.

Stomatal resistance incorrectly dependent on vegetation fraction

The radiation absorbed by the canopy is a grid quantity and therefore so is PAR (sunlit and shaded). When PAR is used to calculate stomatal resistance, this results in a vegetation fraction dependence on stomatal resistance. A quick test by dividing PAR by vegetation fraction in the inputs to stomatal resistance corrects this dependence so there are two possible solutions:

  1. remove the scaling of PAR before sending to stomatal resistance calculation
  2. a more general but larger solution (and I think preferable) is to remove the scaling on canopy absorbed radiation and apply it later when the grid average components are done at the end of the energy routine.

Table parameters overwritten by 2D parameters in single-point simulation

For crop model and wetland model, single-point simulation reads parameter values from the table and regional simulation from 2D parameters from setup file.
However, when these 2D parameters requested by regional simulation would overwrite table parameters in single-point simulation, occurred in transferring in variables in BiochemVarInMod.F90 and WaterVarInMod.F90.

For example in crop planting date:

if ( OptCropModel == 1 ) then
noahmp%biochem%param%DatePlanting = NoahmpIO%PLANTING(I,J)
noahmp%biochem%param%DateHarvest = NoahmpIO%HARVEST(I,J)
noahmp%biochem%param%GrowDegDayEmerg = NoahmpIO%SEASON_GDD(I,J) / 1770.0 * &
noahmp%biochem%param%GrowDegDayEmerg
noahmp%biochem%param%GrowDegDayInitVeg = NoahmpIO%SEASON_GDD(I,J) / 1770.0 * &
noahmp%biochem%param%GrowDegDayInitVeg
noahmp%biochem%param%GrowDegDayPostVeg = NoahmpIO%SEASON_GDD(I,J) / 1770.0 * &
noahmp%biochem%param%GrowDegDayPostVeg
noahmp%biochem%param%GrowDegDayInitReprod = NoahmpIO%SEASON_GDD(I,J) / 1770.0 * &
noahmp%biochem%param%GrowDegDayInitReprod
noahmp%biochem%param%GrowDegDayMature = NoahmpIO%SEASON_GDD(I,J) / 1770.0 * &
noahmp%biochem%param%GrowDegDayMature
endif

When 2D crop input is missing, hard-coded values (126 and 290) are used in IO_code/module_NoahMP_hrldas_driver.F:

https://github.com/NCAR/hrldas/blob/dca5c8554cec5c8b7edc1c76d8585c6e37b40744/hrldas/IO_code/module_NoahMP_hrldas_driver.F#L277-L284

Suggest change:

  1. in IO_code/module_hrldas_io_netcdf.F, when reading 2D crop input, if variables are missing, pass default value from table.
  2. merge two variable names, NoahmpIO%PLANTING(I,J) from 2D file and NoahmpIO%PLTDAY(CropType) from table.

bug for Irrigation parameter table read

Users report this bug for WRF debug mode using Noah-MP: https://forum.mmm.ucar.edu/threads/floating-point-exception-phys-module_sf_noahmplsm-f-at-noahmp_sflx-subroutine.15638/#post-39058

Here is what from the WRF users. This needs to be fixed soon:
"
I agree, it does not make sense that the reading of namelist does not work in debug compilation mode. For sure is that, in debug mode, we can not operate with 'NaN' variables, which it is not checked in production mode and for sure compiled with optimization > -O2

I realized that the call to read the irrigation parameters (subroutine read_mp_irrigation_parameters from phys/module_sf_noahmpdrv.F) is done within NOAHMP_INIT called in phys/module_physics_init.F, which has:
Code:
if(iopt_irr >= 1) call read_mp_irrigation_parameters()
Therfore, as in my case, if you are not using irrigation iopt_irr=0, irrigation parameters are never read. Which might explain, why it does not have any value...?
So maybe, should the NOAHMP_INIT be modified, and introduce 'default' values to the irrigation_parameters values, to overcome the situation when irrigation is not used? Something like (I use the default values as they appear in read_mp_irrigation_parameters):
Code:
! Default values
IRR_FRAC_TABLE = -1.0E36 ! irrigation Fraction
IRR_HAR_TABLE = 0 ! number of days before harvest date to stop irrigation
IRR_LAI_TABLE = -1.0E36 ! Minimum lai to trigger irrigation
IRR_MAD_TABLE = -1.0E36 ! management allowable deficit (0-1)
FILOSS_TABLE = -1.0E36 ! fraction of flood irrigation loss (0-1)
SPRIR_RATE_TABLE = -1.0E36 ! mm/h, sprinkler irrigation rate
MICIR_RATE_TABLE = -1.0E36 ! mm/h, micro irrigation rate
FIRTFAC_TABLE = -1.0E36 ! flood application rate factor
IR_RAIN_TABLE = -1.0E36 ! maximum precipitation to stop irrigation trigger
if(iopt_irr >= 1) call read_mp_irrigation_parameters()
Although it would be more elegant if irrigation_parameters is called including the iopt_irr parameter and then inside:
Code:
(...)
IF (iopt_irr >= 1) THEN
inquire( file='MPTABLE.TBL', exist=file_named )
if ( file_named ) then
open(15, file="MPTABLE.TBL", status='old', form='formatted', action='read', iostat=ierr)
(...)
read(15,noahmp_irrigation_parameters)
close(15)
END IF
And modify its call from NOAHMP_INIT as:
Code:
call read_mp_irrigation_parameters(iopt_irr)
"

Attempt to output variable RS (total stochastic resistance)or LAISUN and LAISHA

Hello
I am trying to output variables RS (total stochastic resistance) or LAISUN and LAISHA in wrf chem, and I am working on modules_sf-noahmplsm Attempts were made to modify the F file, but none were successful, and the variables outputted during the modification in the Registry.EM-COMMON file of wrf did not have values.
If you could provide some guidance, I would be grateful

Noah-MP release plan

  • Dynamic irrigation model: originated (Prasanth's three schemes): Prasanth, Cenlin

  • Dynamic crop rooting depth: originated (Liu)

  • Tile-drainage model: originated (Prasanth, Baralge, Gochis): Prasanth, Cenlin

  • VIC/XianAnJiang models, (depending on WRF-Hydro testing and need)

WRF-related

  • WRF-Urban enhancement (solar panel, green-roof in BEP/BEM, new urban turbulence scheme; originated by Andreas Zonato)
  • fix the grand heat flux sign and modify the grid-calculation of grand heat flux in LSM drivers.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.