meteorological forcing datasets

91 views
Skip to first unread message

suraj shrestha

unread,
Dec 4, 2025, 3:51:05 PM12/4/25
to Amanzi-ATS Users
Hi all,
While using Daymet, there was no error; however, using AORC datasets caused error even though i filled up NaN, such as "what():  Assertion: "longwave > 0."" 
Can we use any other meteorological dataset?
Thank you
Suraj

Rathore, Saubhagya

unread,
Dec 4, 2025, 3:57:07 PM12/4/25
to suraj shrestha, Amanzi-ATS Users
Hi Suraj,

The error is mostly likely due to NaNs at the edges that get interpolated. When you download AORC data through Watershed Workflow, buffer the domain boundary by 100-200 meters and you should be good. Something like watershed.exterior().buffer(200).

Thanks,
Saubhagya

From: ats-...@googlegroups.com <ats-...@googlegroups.com> on behalf of suraj shrestha <theshres...@gmail.com>
Date: Thursday, December 4, 2025 at 3:51 PM
To: Amanzi-ATS Users <ats-...@googlegroups.com>
Subject: [EXTERNAL] meteorological forcing datasets

This Message Is From an External Sender
This email was sent from a non-ORNL address. If suspicious, use the Report Phish button in Outlook.
 
--
You received this message because you are subscribed to the Google Groups "Amanzi-ATS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ats-users/6004e5bf-ee03-4846-9189-81b925676c5an%40googlegroups.com.

Pin Shuai

unread,
Apr 6, 2026, 12:16:06 PMApr 6
to Amanzi-ATS Users
Hi Suraj,

Did you find a fix? My student has encountered the same issue with the AORC dataset even after replacing all the NaNs with zeros.

We also tried removing all the longwave dataset in the xml file, but then ATS complained about missing "longwave" in the state variables. 

I think we can let ATS calculate longwave internally, but is the following enough?

```
      <ParameterList name="surface-incoming_longwave_radiation" type="ParameterList">
        <Parameter name="evaluator type" type="string" value="incoming longwave radiation" />
      </ParameterList>
```

Thanks,
Pin

Ethan Coon

unread,
Apr 6, 2026, 1:01:33 PMApr 6
to Pin Shuai, Amanzi-ATS Users
Yes, that is right to compute longwave.

Are you in a coastal domain where your basin might overlap with the ocean?  Can you look at a map of where it is NaN and see what is going on there?

Ethan


-------------------------------------------------------------------
Ethan Coon
917-969-6831
https://www.ornl.gov/staff-profile/ethan-t-coon
-------------------------------------------------------------------


suraj shrestha

unread,
Apr 6, 2026, 2:42:55 PMApr 6
to Pin Shuai, Amanzi-ATS Users
Hi Pin Shuai,
I tried every suggestions i got, among them, i first targeted the DLWRF_surface (longwave radiation) variable to replace NaNs with 200 W/m², but still i got some NaNs, so, i again applied global .fillna(0) as a catch-all for any remaining gaps; and finally, I used logical overrides to replace unphysical zeros with constant mean values for critical variables like pressure and temperature.

Suraj



To view this discussion visit https://groups.google.com/d/msgid/ats-users/a5a68a9d-41da-42db-9c4d-39ee4506715dn%40googlegroups.com.

Pin Shuai

unread,
Apr 7, 2026, 6:39:10 PMApr 7
to Amanzi-ATS Users
Hi Ethan,

I have skipped providing the longwave forcing in the xml file following the same Coweeta template: https://github.com/environmental-modeling-workflows/watershed-workflow/blob/master/examples/Coweeta/input_data/cyclic_steadystate-template.xml

However, I am still getting the assertion error. 

terminate called after throwing an instance of 'DBC::Assertion'
Any idea?

Pin

Bo Gao

unread,
Apr 7, 2026, 7:50:17 PMApr 7
to Pin Shuai, Amanzi-ATS Users
Hi Pin,

If that's the case, I guess you should have nans in all your forcings, not just longwave, because longwave is calculated using air temperature in ATS. You can double check by setting longwave to a constant value like 300 and run your model, you may still have some other errors. I would suggest plotting your focings map and watershed together to see whether there are some areas inside the watershed that are not covered by the forcings map, or whether there are CRS conversion issues. 

Bo Gao

To view this discussion visit https://groups.google.com/d/msgid/ats-users/0d01194b-1d4a-4c6c-b7cd-24a2b921eefcn%40googlegroups.com.

Pin Shuai

unread,
Apr 9, 2026, 12:34:40 PMApr 9
to Amanzi-ATS Users
Hi Bo,

We tried buffering the watershed and redownloading the AORC dataset. We filled in all missing values. 

We also tried setting the longwave a constant value like 400, but we got the following error:

```
```

We then tried setting both shortwave and longwave constant, and we got the same error again: 

```
inverse::GMRES     |  Not converged (max iterations), ||r||=nan ||f||=nan
BAD FLUX! on face 0
  flux = nan
  param = nan
  flow_eps = 1e-08

terminate called after throwing an instance of 'DBC::Assertion'
```

It seems like something is wrong with the values associated with the flux calculation. What do you recommend to do?

-Pin

Rathore, Saubhagya

unread,
Apr 9, 2026, 12:37:55 PMApr 9
to Pin Shuai, Amanzi-ATS Users
It might be worth checking if CRS used in your model set up (including meshes) matches with that of downloaded AORC datasets. 

“We then tried setting both shortwave and longwave constant, and we got the same error again: “ — could be because your other variables are also out of domain if there is a CRS mismatch. 

Thanks,
Saubhagya

From: ats-...@googlegroups.com <ats-...@googlegroups.com> on behalf of Pin Shuai <pshu...@gmail.com>
Date: Thursday, April 9, 2026 at 12:35 PM
To: Amanzi-ATS Users <ats-...@googlegroups.com>
Subject: Re: [EXTERNAL] meteorological forcing datasets

This Message Is From an Untrusted Sender
You have not previously corresponded with this sender. If suspicious, use the Report Phish button in Outlook.
 

Coon, Ethan

unread,
Apr 9, 2026, 1:20:29 PMApr 9
to Pin Shuai, Amanzi-ATS Users
You still have nans in your forcing then (or a 0 in your absolute permeability might also cause this error).  We explicitly check the longwave for nans, but not the other met data.  Maybe we need to check all incoming data for NaNs.

There are two ways to see which and where your input data has NaNs:

  1. Are you visualizing your data at step 0 (or checkpointing it)?  I believe you should get a 0th step vis/checkpoint file if so (I think your error is after the initialization step, so those data should be computed and written before you get this error).  Manually open the hdf5 file with h5py and load the incoming precipitation/temp/etc — are those NaN?
  2. Use the Watershed Workflow function ww.getDatasetOnMesh(… method=‘linear') with your met data.  You would never do this in the normal workflow because we just write the met data directly as rasters, but if you do this, you’ll see if the bilinear stencil for computing e.g. temperature on each cell includes a pixel that is NaN.

    aorc = ww.sources.ManagerAORC()
    met_data = aorc.getDataset(…)
    met_data_on_ats_mesh = ww.getDatasetOnMesh(met_data, …, method=‘linear’)
    np.where(np.isnan(met_data_on_ats_mesh))

I suspect one of the following is true:

  1. You didn’t buffer enough (probably not true)
  2. You buffered a reasonable amount, but when you reprojected the data, smoothed the data, or did some other modification to the data, the stencil of that modification used NaNs.  (This is particularly a problem with smoothing and CRS changes.)
  3. You’re at a coastal region where your coastline is offshore and AORC has NaN values offshore, so buffering isn’t helping — it’s just adding more ocean pixels with more NaNs.
  4. You have internal NaNs (AORC shouldn’t have this, but maybe?) and need to do a call to imputeHoles() to fill those NaNs with real values.


I have yet to see a case where AORC has a NaN in one variable and pixel, but does not have a NaN at that same pixel in other variables.  So setting longwave to a constant “fixes" the longwave error, but still does not fix the fact that there are temperature and precipitation values that are NaN at those same pixels.


Ethan





Date: Thursday, April 9, 2026 at 10:35 AM
To: Amanzi-ATS Users <ats-...@googlegroups.com>
Subject: Re: [EXTERNAL] meteorological forcing datasets

This Message Is From an Untrusted Sender
You have not previously corresponded with this sender. If suspicious, use the Report Phish button in Outlook.
 
Reply all
Reply to author
Forward
0 new messages