Some sizes of Fractal Box with Peplinski soil not rendering

[Mark-Dunscomb]

Issue:
I'm note getting a proper distribution from "soil_peplinski" within a "fractal_box" with large modelspace's.
Although my model includes a distribution of "soil_peplinski" parameters via a fractal box, the model only seems to use the first material in the series of variants. Similar but smaller model spaces have no issues but this larger model space does. The issue could be in my input files, the process I'm using, or a size issue related to gprMax. I can't find an issue with my files but it could be there. Any help is appreciated.

Background:
My model space contains multiple materials and I'm calling an antenna from the antenna module to use as TX/RX. The uppermost soil layer is the most important and is created via "soil_peplinski" to incorporate dispersion, etc. I've extended the "soil_peplinski" via a fractal_box with 10 variations. Also, I've saved geometry/materials to h5/txt files and am reading them back in to prevent changes in the fractal box from scan to scan in a B-Scan. The files were written without the antenna module and then I've reintroduced the antenna module to process the model.

What happens:
The materials txt file includes a full series of 10 "soil_peplinski" variants but it appears that only the first variant used in the model and the remainder are not included. I.e. The geometry file only has the first variant soil in it, which fills in the entire soil layer.

I've tried multiple trials to find the issue but haven't found one.
Trials:

• Created a small trial modelspace with similar soil_peplinski and fractal box distribution. Works fine.
• Added an antenna from the antennas module to the small trial modelspace. Works fine.
• Re-wrote the geometry in the .in file to confirm no typo's exist. Same results.
• I can't find a reason for this occurring so perhaps there is a bug (?). Can't be sure.

Pictures are worth more than trying to explain so here are some.

Two images of my small test model space showing that this should work. Note the soil material distribution.

What I get in my project modelspace. The uppermost soil layer should be a distribution of materials but is only the first material in the series. This modelspace is much larger than the small trial model. It has ~5e8 cells.

Here's the materials txt file that includes a full suite of material variations although they don't seem to be included in the model, only the first (the 8th material in this list below). I've attached an input file and would appreciate any help. THANKS!!

#material: 1 inf 1 0 pec
#material: 1 0 1 0 free_space
#material: 6 1.25e-06 1 0 plywood
#material: 6.5 0.0001 1 0 concrete
#material: 4.8 1e-09 1 0 asphalt
#material: 5 0.000333 1 0 GP
#material: 10 0.00125 1 0 GM
#material: 6.28071 0.0251903 1 0 |0.0428|
#add_dispersion_debye: 1 1.61761 9.231e-12 |0.0428|
#material: 6.51023 0.0258702 1 0 |0.0483|
#add_dispersion_debye: 1 1.87702 9.231e-12 |0.0483|
#material: 6.73083 0.0264915 1 0 |0.0539|
#add_dispersion_debye: 1 2.14303 9.231e-12 |0.0539|
#material: 6.94375 0.0270646 1 0 |0.0594|
#add_dispersion_debye: 1 2.4151 9.231e-12 |0.0594|
#material: 7.14995 0.0275972 1 0 |0.0650|
#add_dispersion_debye: 1 2.69278 9.231e-12 |0.0650|
#material: 7.3502 0.0280953 1 0 |0.0706|
#add_dispersion_debye: 1 2.97569 9.231e-12 |0.0706|
#material: 7.54516 0.0285637 1 0 |0.0761|
#add_dispersion_debye: 1 3.2635 9.231e-12 |0.0761|
#material: 7.73534 0.029006 1 0 |0.0817|
#add_dispersion_debye: 1 3.55594 9.231e-12 |0.0817|
#material: 7.92121 0.0294254 1 0 |0.0872|
#add_dispersion_debye: 1 3.85275 9.231e-12 |0.0872|
#material: 8.10315 0.0298244 1 0 |0.0928|
#add_dispersion_debye: 1 4.15372 9.231e-12 |0.0928|
#material: 7.5 0.0007915 1 0 GM+GM+GP+GP
#material: 5.5 0.000167125 1 0 plywood+plywood+GP+GP
#material: 3.5 6.25e-07 1 0 free_space+free_space+plywood+plywood
#material: 5.25 0.000250063 1 0 plywood+GP+GP+GP
#material: 6.75 0.000396375 1 0 plywood+GM+GP+plywood
#material: 8 0.000625625 1 0 plywood+GM+GM+plywood
#material: 4.75 9.375e-07 1 0 free_space+plywood+plywood+plywood

The input file used to generate geometry and material files:

#title: GSSI_400MHz_R2_(0.5m Slice in CH short axis)
#domain: 3.332 0.500 2.400
## NOTE - No cells ~ 5e8
## NOTE - Should take about 64 GB RAM to run
## NOTE - MODELSPACE IS ROTATED 90 DEGREES IN XY PLANE FROM ORIGINAL SETUP TO ENSURE 400MHZ ANTENNA IS IN PROPER ORIENTATION
#dx_dy_dz: 0.002 0.002 0.002
#num_threads: 18
#time_window: 60e-9

##geometry_objects_read: 0 0 0 C:/gprMax/user_models/GSSI_400MHz_R2_geometry.h5 C:\gprMax\user_models\GSSI_400MHz_R2_geometry_materials.txt

## Materials (er, cond, ur, mag loss, ID)
#material: 6.0 1.25e-6 1 0 plywood
#material: 6.5 1.00e-4 1 0 concrete
#material: 4.8 1.00e-9 1 0 asphalt
#material: 5.0 3.33e-4 1 0 GP
#material: 10.0 1.25e-3 1 0 GM
##material: 16.0 3.33e-3 1 0 GC
#soil_peplinski: 0.87 0.13 2.1 2.66 0.04 0.09 GC_pep

## Model Geometry
##  Free space
#box: 0 0 0 3.332 0.500 2.400 free_space 
##  Soil
#fractal_box: 0 0 1.388 3.332 0.500 2.092 1 1 1 1 10 GC_pep GC_fractal_box
#add_surface_roughness: 0.0 0.0 2.092 3.332 0.500 2.092 1 1 1 2.076 2.108 GC_fractal_box
##      REPLACED BY FRACTAL BOX WITH ROUGHNESS box: 0 0 1.39 6.482 1.958 2.092 GC
#box: 0 0 0.572 3.332 0.500 1.388 GM 
#box: 0 0 0.000 3.332 0.500 0.572 GP
##  Structure
#fractal_box: 0.972 0.000 0.752 2.360 0.500 1.304 1 1 1 1 1 concrete concrete_fractal_box
##top
#add_surface_roughness: 0.972 0.000 1.304 2.360 0.500 1.304 2.2 1 1 1.288 1.320 concrete_fractal_box
##x1
#add_surface_roughness: 0.972 0.000 0.752 0.972 0.500 1.304 1.5 1 1 0.956 0.988 concrete_fractal_box
##x2
#add_surface_roughness: 2.360 0.000 0.752 2.360 0.500 1.304 1.5 1 1 2.344 2.376 concrete_fractal_box
##     REPLACED BY FRACTAL BOX WITH ROUGHNESS - box: 1.000 0.276 0.752 5.480 1.658 1.305 concrete
#box: 1.000 0.000 0.200 2.332 0.500 1.268 plywood
##carve out interior of CH
#box: 1.024 0.000 0.236 2.308 0.500 1.216 free_space


## RX/TX Info
##  GSSI 400MHz Antenna
##python:
##from user_libs.antennas import antenna_like_GSSI_400
##   Collect data every 1.6 cm = 0.63 inches = 1.59 scans/in
##   from 0.18m to 3.304m => 195 scans
##antenna_like_GSSI_400(0.18 + current_model_run * 0.016, 0.252, 2.092, resolution=0.002)
##end_python:


## Geometry Files
#geometry_objects_write: 0 0 0 3.332 0.500 2.400 GSSI_400MHz_R2_geometry
#geometry_view: 0 0 0 3.332 0.500 2.400 0.002 0.002 0.002 GSSI_400MHz_R2 n

My input file used to run the model:

#title: GSSI_400MHz_R2_(0.5m thick Slice in CH short axis)
#domain: 3.332 0.500 2.400
## NOTE - No. cells ~ 5e8
## NOTE - Should take about 64 GB RAM to run
## NOTE - THIS IS ROTATED 90 DEGREES IN XY FROM ORIGINAL SETUP TO ENSURE 400MHZ ANTENNA IS IN PROPER ORIENTATION
#dx_dy_dz: 0.002 0.002 0.002
#num_threads: 18
#time_window: 60e-9

## MODEL GEOMETRY
##geometry_objects_write: 0 0 0 3.332 0.500 2.400 GSSI_400MHz_R2_geometry
#geometry_objects_read: 0 0 0 user_models/GSSI_400MHz_R2_geometry.h5 user_models/GSSI_400MHz_R2_geometry_materials.txt

## RX/TX Info
##  GSSI 400MHz Antenna
#python:
from user_libs.antennas import antenna_like_GSSI_400
#   Collect data every 1.6 cm = 0.63 inches = 1.59 scans/in
#   from 0.18m to 3.304m => 195 scans
antenna_like_GSSI_400(0.18 + current_model_run * 0.016, 0.252, 2.092, resolution=0.002)
#end_python:

## GEOMETRY VIEW FILES
#geometry_view: 0 0 0 3.332 0.500 2.400 0.002 0.002 0.002 GSSI_400MHz_R2 n

[craig-warren]

@Mark-Dunscomb I've only had a chance to have a quick look at this so far, but my suspicion is that this is some sort of issue with Paraview reading the file. Certainly the dictionary which lists all the materials in the model is being written to the geometry file (I can see this by simply running tail on the file). However, even trying a manual threshold of material values above 7 (which is the beginning of the Peplinski materials) does not display any output in Paraview. My next task is to double check that the material indices are being correctly written to the geometry file. If that is the case then the bug is definitely with Paraview, and we can focus efforts there.

[Mark-Dunscomb]

@craig-warren Thanks Craig. I've run into this several times, always on larger models. Although it would be nice to see the variation, displaying is less important than knowing that the output was calculated using the variation. The difficult part is, as you said, although the materials are listed, there doesn't seem to be related data. Or.. Paraview has some type of issue. Thanks again for your help.

[craig-warren]

@Mark-Dunscomb so a quick test suggests that the material IDs from the Peplinski model and fractal distribution (#fractal_box) are being correctly written to the geometry file. Do you have an idea/can you check what size of model the geometry file stops working? This would help me try to narrow down the issue.

Thanks,
Craig

[Mark-Dunscomb]

@craig-warren I don't have that info but will set up a batch file to test it and will let you know. Might need to run it over the weekend. Thanks.

[Mark-Dunscomb]

@craig-warren Results of a quick test. I ran the same model (one I had used for speed benchmarking) multiple times but increased the no. of cells each time by reducing the cell size. The results:

Very strange. Model 3 only had 3 materials in it; the box, the lower soil, and only the first form of the Peplinski model distribution of parameters. Also, I was only able to use the gprMax_info macro on the second model. For the other 3, I had to manually run through the threshold filters. Images below of the 4 models. The input files I used are also attached in a zip file.

user_models.zip

[craig-warren]

@Mark-Dunscomb quick check, the spatial resolutions you are using on the geometry views do not match the spatial resolutions of the models. Was this intended? Whilst, in theory, this should not be an issue lets keep them the same for now. Models 3 and 4 are a bit too big (in terms of memory) for me to attempt to render on my desktop machine. Models 1 and 2 display OK for me with the gprMax macro.

[Mark-Dunscomb]

@craig-warren Hi Craig. Thanks, the mismatch was intended to limit the size of the vti files but probably was not a great idea when testing. I changed it so that the geometry files have the same discretization as the respective model spaces and then re-ran them. All results are the same. Afterward, I ran several other files trying to isolate the issue but have been unsuccessful. See results below:

I've re-run model no. 3 multiple times and viewed ways in Paraview and have the same results every time.

I thought it could be a memory issue but that doesn't seem to be the case. Smaller models, larger models, and models around the same size as model 3 all seem to be fine.

Then I thought it could be a mismatch issue in the discretization but that doesn't seem to be the case. Model no. 2 purposely has a mismatch and works fine. Also, I've checked and rechecked to confirm there are no odd issues in model no. 3.

Thought it could be an issue with the way materials are defined or what is included but that doesn't seem to be the case. Models 3 and 6 are the same with the exception of discretization in the z direction. 6 works, 3 doesn't. Also, models 3 and 11 have the same discretization but different materials and neither works.

I've attached .in files for models 3, 6 and 11. 3 and 11 have the same discretization and 6 is only slightly different (change in z discretization). My best guess is that there is an issue with the discretization but it's eluding me.
user_models.zip

[Jay201733]

I believe that my query is something relevant as well.

I followed two steps for my simple model:

1. Generate the soil Peplinski model using line 12, 13, 19 of my snapshot
2. run b-scan on a fixed distribution of soil properties by importing the geometry and material properties used in the step 1.

Problem that I am facing: Even though i can clearly see .h5 file and .txt file generated in the step1, while reading them in the bscan model, i am getting an error that materials.txt file is not found.

I have attached the snapshot for your reference with some comments, please suggest what can i do to fix it.

Regards
Jay

[Jay201733]

the above problem got fixed when i changed the name of the files. not sure if there was some specific requirement for the file names. Thanks!