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
74 stars 42 forks source link

Possible intersection skip #2

Closed jordisanglas closed 5 years ago

jordisanglas commented 5 years ago

The general structure of a dfnTrans timestep is (lots of details omitted!):

  1. If the particle is inside a cell in contact with an intersection, CheckDistance() is called. Inside it, the particle's distance to the intersection is computed. If it is close to the intersection, a PredictorStep() is performed and we check if it crossed the intersection. In that case, AcrossIntersection() is called.
  2. Regardless of step 1, another PredictorStep() is always done (sometimes followed by a CorrectorStep()).

If I understand it correctly, the following issue might happen:

  1. A particle is close to an intersection, so a predictor step is performed in step 1. Maybe it does not cross the intersection, it only gets closer to it.
  2. Then, the second PredictorStep() is called and the particle crosses the intersection. However, it is not detected, as the second call to PredictorStep() does not check for intersection crossings.

That means that a particle can cross an intersection without it being detected. If I'm not mistaken, this happens in the truncated_power_law_dist test, for particle np=7 when it is at fracture 3 and crosses fracture 169 without noticing. This can only be seen by debugging the code, and seeing that the particle crosses fracture 169 without calling AcrossIntersection(). However, I do not know if it happens often or it is a rare event.

Am I missing something or is it a small bug?

dfnWorks commented 5 years ago

Thank you for your comment, I am looking into it now. Is it possible to get the mesh and DFN run you are referring to? could you archive it and send it through transfer.lanl.gov to nataliia at lanl.gov. thanks

jordisanglas commented 5 years ago

Hi,

What files would you need in particular? The whole folder is 1.5 GB. Note that the bug can be reproduced in the truncated_power_law_dist test that is already included when installing dfnWorks.

dfnWorks commented 5 years ago

I am not going to regenerate the fracture network, I am not sure in my computer it will give me exact the same DFN and mesh that you have. It will be great if you can send me exactly the same mesh that you used to get to dfnTrans. If sending files is a problem, then, sure, I can look at the test at dfnWorks package.

jordisanglas commented 5 years ago

I have sent the folder (I was not sure which files were needed). dfnTrans has already been run, but you can run it again when debugging.

dfnWorks commented 5 years ago

Got it, thank you. I will look at the problem and answer your questions soon.

dfnWorks commented 5 years ago

Thanks again for your comment, it let me look again at another pathological case. In dfnTrans particles are moving according to predictor-corrector algorithm. Predictor and corrector steps are performed at every time step during particle movement, regardless of the cell location: boundary cell, or regular cell inside a fracture, or an intersection cell (this is Step 2 at your comment). In step 1, predictor step is used to move particles through the intersection and to make sure that during next predictor-corrector step it will cross an intersection line. Here, no new position no new velocities of the predictor step are used. Once it is detected that particle will cross an intersection, particle is moved back to the point where the particle's trajectory crosses intersection line, then AcrossIntersection is called and the new fracture (or the same fracture) is chosen and new velocities are calculated. In the case of truncated_power_law_dist test, the intersection line is almost parallel to the flow and the angle between particle's trajectory and intersection line is narrow. Moreover, the particle position before the intersection was detected is very close to the intersection node. When the predictor step was performed, the code didn’t identify the previous and new particle position on different sides of the intersection. This is a rare event. I made a little fix there, it will be available on repo next week.

jordisanglas commented 5 years ago

Thank you! If it is a rare event, I guess it does not affect much the results.