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

PRT model EMS freezes with quadtree disv grid #1857

Open
robinkeegan opened this issue Jun 6, 2024 · 6 comments
Open

PRT model EMS freezes with quadtree disv grid #1857

robinkeegan opened this issue Jun 6, 2024 · 6 comments
Labels

Comments

@robinkeegan
Copy link

I have a groundwater flow model with a disv quadtree grid generated with gridgen. I am running the PRT model using the cell-by-cell budget and heads files from the groundwater flow model. The PRT model runs to completion if I release the particles where the resulting path line does not pass through any refined cells. However, if I change the release location and the particles encounter a refinement along the flow paths the model gets stuck solving. Interestingly there isn’t a convergence error and it just keeps trying to solve at the current time step, although never getting past the current step. I tried both reducing and increasing the convergence criteria but that didn’t fix the issue.

I did see this previous issue raised by Rui and was wondering if the limitation around quad tree grids been resolved? If so, does anyone have an idea what could be causing this issue?
#1434 (comment)

I am using MF 6.5.0 on windows 11.

Thanks

Robin

@robinkeegan robinkeegan added the bug label Jun 6, 2024
@wpbonelli
Copy link
Contributor

@robinkeegan thanks for reporting this. The issue discussed in #1434 should be resolved, though it's possible you've discovered an edge case or an altogether different bug.

Is the model hanging in an internal time step, or is it the simulation's last? One way this could happen is if your particles are stuck in a cycle in the flow field. By default particles are tracked beyond the end of the simulation until they terminate, as MODPATH would with stop time option 2 (we have discussed changing this in a soon forthcoming release as it can not only hang but can easily eat all the machine's available disk space). Do you see any rows getting added to the track output file when it gets stuck? To rule out this possibility you could also try setting a STOPTIME in the PRP package.

If this happens in an internal time step there is something else going on.

@wpbonelli
Copy link
Contributor

Another thought: do your refinement levels change abruptly? I.e. do you have shared faces with more than one "extra" vertex, from the perspective of the less-refined cell? We have discussed this situation but we don't have a test case covering it yet.

@robinkeegan
Copy link
Author

robinkeegan commented Jun 6, 2024

@wpbonelli thankyou for looking into this so quickly.
The error occurs at stress period 24 timestep 13. There are 140 stress periods and 30 timesteps per stress period so it isn't the last timestep. No additional rows are being added to the tracks csv when the solver has frozen.
The screenshot shows the position of the particle prior to the solver freezing. The track is shaded from white to blue where white is 0 days elapsed and blue is 320 days. It seems like the issue occurs when the particle is moving from cell 24897 to 24902.

image

@wpbonelli
Copy link
Contributor

@robinkeegan are you able to share this model? That would help get to the bottom of this quickly. Please feel free to upload here or email to

  • wbonelli [at] ucar [dot] edu
  • aprovost [at] usgs [dot] gov

If it's under wraps we will need to try to reproduce independently — in this case any/all info you can provide would help, in particular about the grid. It would be a huge help to see (perhaps just the relevant portion of) the DISV input file.

@robinkeegan
Copy link
Author

@wpbonelli apologies I can't share the model but I will attempt to put together a similar example at some stage in the next week and will email it through.

@wpbonelli
Copy link
Contributor

#1874 fixes a problem which may be related to this issue — particles encountering sinks were not terminated properly, causing the program to enter an endless loop. @robinkeegan the patch will be included in tonight's build

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

No branches or pull requests

2 participants