search

lanl / dfnWorks

dfnWorks is a parallelized computational suite to generate three-dimensional discrete fracture networks (DFN) and simulate flow and transport. If you download the software please fill out our interest form to stay up to date on releases https://goo.gl/forms/VE39oKsyp4LVC6Gj2 and join our google group https://groups.google.com/d/forum/dfnworks-users . Precompiled Docker Container https://hub.docker.com/r/ees16/dfnworks
https://dfnworks.lanl.gov/
Other
73 stars 42 forks source link

dfnGen fails with user defined fractures #56

Open DaveHealy-github opened 1 year ago

DaveHealy-github commented 1 year ago

When I run dfnGen with a custom Python script containing say 700 fractures, the code blows up in the Python module hydraulic_properties.py, with a list index exception. The error reads:

Traceback (most recent call last): File "/home/daveh/dfnWorks/FracPaQpy/FracPaQpyDFN.py", line 787, in DFN.create_network() File "/home/daveh/anaconda3/lib/python3.10/site-packages/pydfnworks/dfnGen/generation/generator.py", line 141, in create_network self.assign_hydraulic_properties() File "/home/daveh/anaconda3/lib/python3.10/site-packages/pydfnworks/dfnGen/generation/generator.py", line 416, in assign_hydraulic_properties self.set_fracture_hydraulic_values(hy_prop_type, [fracture_num], File "/home/daveh/anaconda3/lib/python3.10/site-packages/pydfnworks/dfnGen/generation/hydraulic_properties.py", line 545, in set_fracture_hydraulic_values self.aperture[fracture_list - 1] = b IndexError: index 749 is out of bounds for axis 0 with size 749

An example of one of my scripts is attached below (with .py changed to .txt) I think the problem lies with the tracking of how many fractures to assign apertures (or other values) to; in this case, I had 765 original fractures, but only 749 after isolated ones were removed. The loop in the above code is defined on the range provided by the length of user_rect_params (i.e., 765 in this case), but the aperture list on the DFN object is sized to the reduced fracture set (749 in this case). fracpaqpyDFN.txt

hymanjd commented 1 year ago

@aidanstansberry Can you take a look?

aidanstansberry commented 1 year ago

There is a straightforward workaround on your end while we work on a fix on our end. If the user fracture is rejected during network generation, we have already stored the hydraulic property value in an array hence the error message. You can comment out any rejected fractures in your input and that should alleviate the error.

Look for lines like this in the output and comment out the corresponding user fractures

Rejected user defined rectangular fracture 695 rejectCode = -6: Fracture too close to another fracture's edge.

DaveHealy-github commented 1 year ago

Ace, I'll give that a try. Thanks.

DaveHealy-github commented 1 year ago

Sadly, that didn't work. I commented out the ones being Rejected and that gets me n=749. But then the workflow removes Isolated fractures down to n=666 - and they are not specifically listed on the console. It is this discrepancy (n=749 versus n=666) that is causing the index error, I think.

aidanstansberry commented 1 year ago

It looks like the same issue occurs when we remove isolated fractures from the domain. If you just want to visualize the DFN add these flags to the script

DFN.params['keepIsolatedFractures']['value'] = True DFN.params['visualizationMode']['value'] = True

Hopefully this helps.

DaveHealy-github commented 1 year ago

Thanks again - and yes, that works! That will enable me to move forwards for a while.

DaveHealy-github commented 1 year ago

Just thinking, it would be v useful to get the rejected fractures from dfnGen listed in a file. I can then script something to comment these out in the next run... Thanks, Dave

hymanjd commented 1 year ago

We will talk about how to do this and let you know when we have a fix. Thanks for the patience and suggestions