The number of blocks in mulgrid is different whne importing Leapfrog generated input files
Closed this issue · 4 comments
Dear PyTOUGH developers,
First of all, I really want to say thank you for your works developing this excellent tools and making it public.
Currently, I'm trying to import a MULgraph geometry file and TOUGH data file, which are created and exported by a commercial software (Leapfrog), in PyTOUGH.
I was able to create mulgrid and t2data objects from the two files without any errors.
However I noticed that the number of grid blocks in the mulgrid object is not same as that in the TOUGH data file. For this specific example, the last three cells defined in ELEME block in the file are missing in the mulgrid object.
So far I have no clue about whether this is Leapfrog problem or PyTOUGH problem, or I missed some configuration in mulgrid.
It would be very helpful if anyone experienced similar problem can give me advice.
Thank you in advance,
Norihiro
hi Norohiro, just to clarify, are both the geometry file and data file exported from Leapfrog?
There are several possible reasons why those 3 blocks are not present in the geometry file. The first thing I would do is check their volumes to see if they are either inactive (zero volume) or have large volumes, in which case they might be representing boundary conditions in the model and hence would not be present in the geometry.
If that is not the case, it's hard to tell exactly what is going on without seeing the files- you are welcome to share them with me if you would like me to take a look.
Hi @acroucher ,
Many thanks for the reply! Yes, both are exported from Leapfrog (ver 2023.2.3). Those 3 blocks have neither zero volume nor large volumes.
In this morning, I haved checked it in more detail using PyTOUGH and figured out that the missing cells are actualy not the last 3 blocks (I thought the last 3 blocks are missing because write_vtk() claimed these blocks are missing in rocktype). The actuall missing 3 blocks have z values which are very slightly above surface elevation given in the geometry file (e.g. cell center z value of +0.001 against surface elevation being set to 0.0). It seems that Leapfrog accepts these cells while PyTOUGH does not, though I guess PyTOUGH is doing correct. I confrimed that, with slightl increase of the elevations in the file, PyTOUGH can accept the three cells and have the same number of grids as the data file.
So the block centre z values are above the surface elevations for their columns? In that case, I don't know why Leapfrog would include them.
Yes. Maybe they are using a larger tolerance in the comparison of z values.
For now, I'll report this issue to the compnay, and play with PyTOUGH to fix the grid and data.
Thank you for your support!