control_p8_atmlnd_intel fails in debug mode

[DeniseWorthen]

Description

When running the control_p8_atmlnd_intel test in debug mode, it fails with

forrtl: severe (408): fort: (3): Subscript #1 of the array LAIM_TABLE has value 0 which is less than the lower bound of 1

Image              PC                Routine            Line        Source
fv3.exe            000000000E2DF516  lnd_comp_types_mp         731  lnd_comp_types.F90
fv3.exe            000000000E26D7E9  lnd_comp_driver_m         286  lnd_comp_driver.F90
fv3.exe            000000000E25EF9C  lnd_comp_nuopc_mp         458  lnd_comp_nuopc.F90
fv3.exe            0000000000CA2688  Unknown               Unknown  Unknown

To Reproduce:

Compile and run in debug mode.

Additional context

Output

[DeniseWorthen]

@uturuncoglu @barlage I was working on putting cpl_scalars into noahmp and ran across this failure while testing.

[uturuncoglu]

@DeniseWorthen Let me check. Which machine is this and compiler? I am assuming that this is tested in every PR. Maybe the component land needs to be synced with CCPP version if there is a change over there. Since, noahmp is not submodule at this point, we are having two copies of it. One in component model and other is in FV3 and both needs to be same.

[DeniseWorthen]

I was testing on derecho+intel. There is no debug test for this config, but I assume it passed the the ORT when first committed. Once it gets fixed, we should add a debug test.

[uturuncoglu]

@DeniseWorthen Okay. Are you compiling with debug mode? Maybe there is a bug that we missed.

[uturuncoglu]

@DeniseWorthen Okay. I see now. It is debug mode. I am looking at this point.

[uturuncoglu]

@barlage Following is the part of the code that we have issue,

https://github.com/NOAA-EMC/noahmp/blob/0cd3e23ae5d35ef93e205e4d0c3b13ccc0d851f5/drivers/nuopc/lnd_comp_types.F90#L731

Since I got that part from ufs-land-driver, I also check that one to see anything changed or not

https://github.com/NOAA-EMC/ufs-land-driver/blob/998e3d46be1c04b19b639f4c34153ddbdf63c974/driver/ufsLandNoahMPType.f90#L2814C1-L2815C1

It seems that both side uses very similar code. Maybe there is something with the masking etc. and vegtype goes to zero. I am plaining to put some print statements to see the actual cause.

[uturuncoglu]

@barlage okay. it seems that the point that code fails is not land. So, the table gets 0. I think if I put check with mask to the loop, that will solve the problem. I think you have no any issue in your case since you are running code explicitly only over land points since ifs-land-driver uses vector format.

[DeniseWorthen]

Closed; Issue is created in #2189