Skip to content
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

Tolerance issue when reading boundary data using native format #768

Open
rthedin opened this issue Jan 3, 2023 · 1 comment
Open

Tolerance issue when reading boundary data using native format #768

rthedin opened this issue Jan 3, 2023 · 1 comment

Comments

@rthedin
Copy link

rthedin commented Jan 3, 2023

When running a case that takes boundary data as input, it fails on this assert:

AMREX_ALWAYS_ASSERT((m_in_times[0] <= time) && (time < m_in_times.back()));

I have a simple test case that starts at 19500 s, with boundary data saved starting at the same time. The format of the boundary data saved is native (as netcdf still seems to be really slow). I have added a few print statements right before the assert to try to debug it, and this is what I got:

--- DEBUG: m_in_times[0]       is  19500
--- DEBUG: m_in_times.back     is  19530.3
--- DEBUG: time                is  19500
--- DEBUG: time-m_in_times[0]  is  -2.391971066e-08

Given the value of time-m_in_times[0], it seems like a tolerance issue and something like an eps is needed somewhere in that assert statement. The case runs fine if I manually add, say, 19499.7 to the boundary data.

One additional piece of information: The simulation that saved the boundary data was split into two parts, the first ending at 19500 and the second starting at the same time. Since m_in_times[0] seem to be slightly (tolerance) higher than 19500, that could be one of the causes of the problem.

@github-actions
Copy link

This issue is stale because it has been open 30 days with no activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant