Question about libc++abi assertation error

15 views
Skip to first unread message

Chuyang Liu

unread,
Nov 6, 2025, 2:13:11 PMNov 6
to Amanzi-ATS Users
Hi there,

Many thanks for the prompt help in the previous post. I was able to run the Coweeta steady-state case after commenting out a few observation variables in the ats_input_spec-generated input. Using the same approach for my study area, the ats_input_spec-generated steadystate.xml fails at the first step with the assertion below. Any hints would be greatly appreciated.

=============================================================================================
ATS                |    ... completed: 27.4857 / 27.4904 / 27.4915 (min/mean/max) [s]
ATS                |  ================================================================================
ATS                |  Beginning run creation stage...
ATS                |    ... completed: 0.004319 / 0.00432717 / 0.004336 (min/mean/max) [s]
ATS                |  ================================================================================
ATS                |  Beginning setup stage...
ATS                |    ... completed: 0.087431 / 0.0913622 / 0.09474 (min/mean/max) [s]
ATS                |  ================================================================================
ATS                |  Beginning initialize stage...
State              |  initializing data through initial conditions...
ATS                |    ... completed: 0.082842 / 0.082854 / 0.082859 (min/mean/max) [s]
ATS                |  ================================================================================
ATS                |  Beginning timestepping stage...
ATS                |  ================================================================================
ATS                |  
ATS                |  Cycle = 0,  Time [days] = 0,  dt [days] = 5.787037037037037e-05
ATS                |  --------------------------------------------------------------------------------
Top level MPC      |  ----------------------------------------------------------------
Top level MPC      |  Advancing: t0 = 0 t1 = 5 h = 5
Top level MPC      |  ----------------------------------------------------------------
subsurface flow    |  ENorm (Infnorm) of: water_content:
subsurface flow    |    ENorm (face) = [520775] 0.00367463 (377.118)
subsurface flow    |    ENorm (cell) = [196573] 0.00364015 (187.656)
surface flow       |  ENorm (Infnorm) of: surface-water_content:
libc++abi: terminating due to uncaught exception of type DBC::Assertion: Assertion: "(atol_ * cv[0][c] + rtol_ * std::abs(conserved[0][c])) > 0." failed in file: /Users/XXX/Software/ats-1.6_release/amanzi/src/physics/ats/src/pks/pk_physical_bdf_default.cc, at line: 130

[xxx:10452] *** Process received signal ***
[xxx:10452] Signal: Abort trap: 6 (6)
[xxx:10452] Signal code:  (0)
[xxx:10452] [ 0] 0   libsystem_platform.dylib            0x000000019e03ea24 _sigtramp + 56
[xxx:10452] [ 1] libc++abi: terminating due to uncaught exception of type DBC::Assertion: Assertion: "(atol_ * cv[0][c] + rtol_ * std::abs(conserved[0][c])) > 0." failed in file: /Users/XXX/Software/ats-1.6_release/amanzi/src/physics/ats/src/pks/pk_physical_bdf_default.cc, at line: 130

[xxx:10454] *** Process received signal ***
[xxx:10454] Signal: Abort trap: 6 (6)
[xxx:10454] Signal code:  (0)
[xxx:10454] [ 0] 0   libsystem_platform.dylib            0x000000019e03ea24 _sigtramp + 56
[xxx:10454] [ 1] 0   libsystem_pthread.dylib             0x000000019e00fc28 pthread_kill + 288
[xxx:10454] [ 2] 0   libsystem_c.dylib                   0x000000019df1dae8 abort + 180
[xxx:10454] [ 3] 0   libsystem_pthread.dylib             0x000000019e00fc28 pthread_kill + 288
[xxx:10452] [ 2] 0   libsystem_c.dylib                   0x000000019df1dae8 abort + 180



Thanks,

Chuyang

Bo Gao

unread,
Nov 6, 2025, 7:17:27 PMNov 6
to Chuyang Liu, Amanzi-ATS Users
Hi Chuyang,

The "conserved" here means surface water content, which is calculated using surface pressure, the primary variable. Theoretically, "(atol_ * cv[0][c] + rtol_ * std::abs(conserved[0][c])) " should not be zero or negative given the default tolerance value, then one possibility is either "cv" (surface cell volume) or surface water content  (or both) is nan. If so, it seems ATS cannot identify your surface region. Maybe there is something wrong with your mesh, or something wrong with the surface region definition in your input file.

Best,
Bo Gao

--
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/0bb3e971-6c7e-459e-aec8-9a80693eab03n%40googlegroups.com.

Ethan Coon

unread,
Nov 6, 2025, 9:42:48 PMNov 6
to Bo Gao, Chuyang Liu, Amanzi-ATS Users
Yes, as Bo said, something is wrong in your setup here.  Since it got to the first cycle, that means a vis file at cycle 0 can be written.  Open that vis file in Paraview — does it look like you got everything initialized?  

Ethan


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


Chuyang Liu

unread,
Nov 6, 2025, 10:49:26 PMNov 6
to Amanzi-ATS Users
Hi Bo and Ethan,

Thanks for the help! Following your suggestions, I found that one of the surface cells has a negative volume (highlighted in blue below). It appears that my modifications to the stream-aligned mesh algorithms may be causing this issue—I had to adjust those functions to include headwater streams. Do you have any guidance on how to resolve or prevent similar problems during mesh generation in Watershed Workflow?
negative surface cell volume.png
Exo visualization is okay but.png

Best,
Chuyang

Rathore, Saubhagya

unread,
Nov 7, 2025, 8:11:03 AMNov 7
to Chuyang Liu, Amanzi-ATS Users
Hi Chuyang,

This is related to the convexity issue you posted on separate email thread, quoting you below:

“ just wanted to confirm one point for clarity — the convexity check for the m2 polygons is currently used as a safeguard to prevent self-intersecting geometries. However, is it truly necessary to enforce convexity for the confluence cells? My understanding is that our main goal is to ensure that the geometry does not self-intersect (i.e., that no edges cross each other), while strict convexity may not be required.”

You can see the cell you highlighted is non-convex, and we do require strict convexity. For any two neighboring cells, the line connecting their centroids should intersect the shared face interiorly. Convexity ensures this geometric relationship holds, which is important for defining consistent face normals and distances used in the flux approximation. It also maintains orthogonality to the extent possible, as it is not strictly required, severe non-orthogonality can deteriorate flux estimates. 

Workflow should have enforced convexity. Did you bypass hat step?

Thanks,
Saubhagya

From: ats-...@googlegroups.com <ats-...@googlegroups.com> on behalf of Chuyang Liu <CL...@lbl.gov>
Date: Thursday, November 6, 2025 at 10:49 PM
To: Amanzi-ATS Users <ats-...@googlegroups.com>
Subject: [EXTERNAL] Re: Question about libc++abi assertation error

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.
 

Chuyang Liu

unread,
Nov 7, 2025, 12:58:49 PMNov 7
to Amanzi-ATS Users
Hi Saubhagya,

Many thanks for the detailed explanation. I had rewritten the mesh algorithm for the headwater streams, but I was only checking for self-intersections rather than enforcing convexity. I’ll revise the algorithms accordingly to address this issue. Thanks again for the prompt help.

Best,
Chuyang

Ethan Coon

unread,
Nov 7, 2025, 4:01:53 PMNov 7
to Chuyang Liu, Amanzi-ATS Users
I’m a bit surprised that this is the error you got.  There should have been an earlier, clearer error message as soon as the negative cell volume was computed.

I’ll look at this in Amanzi.

Ethan


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

Chuyang Liu

unread,
Nov 7, 2025, 5:28:56 PMNov 7
to Amanzi-ATS Users
Thanks, Ethan. I appreciate you looking into it. Let me know if you need any files or details from my side.

Best,
Chuyang

Reply all
Reply to author
Forward
0 new messages