Errors when using materials different than itu_concrete

[paulalmasan]

Hi, I'm loading a scene to sionna where the buildings have the "itu_concrete" material and the ground is set to "itu_medium_dry_ground". When I'm executing the load_scene() the preview works properly and I can visualize the scene. However, when I'm executing "cm = scene.coverage_map(cm_cell_size=[1,1])" I'm getting the following error:

If I change the material to "itu_concrete" it does work well. I've tried other materials and it only worked when the ground is set to "itu_concrete". Actually, when I try "itu_metal" or "itu_brick" the jupyter kernel dies when loading the scene with load_scene() and I can't even see the preview.

[jhoydis]

Hi,

The issue is that not all ITU materials are defined for the same frequencies (see the Table in the API documentation of RadioMaterials. So you would either need to change the frequency or choose a material that is defined for your frequency of interest. You can also create custom material if you want.

However, the fact that the kernel dies is undesired behaviour that we need to investigate.

[SebastianCa]

Hi @paulalmasan,

Could you please provide a code snippet that reproduces the error?

[paulalmasan]

I've found a bug in the code to convert a scene to Mitsuba format so I'm closing the issue.

[paulalmasan]

Hi again, I was investigating further the error using blender this time and I came up with it again. What I'm trying to do is to load a scene like in the tutorial https://www.youtube.com/watch?v=7xHLDxUaQ7c but when I'm changing the ground materials I'm getting the error mentioned above. I'm attaching the mitsuba files to reproduce the error and a jupyter notebook. In the folder you can see that when loading the "scene_concrete.xml" it should work but not with "scene_dry_ground.xml". The files are the same but with a different ground material. Both files were generated with Mitsuba and Blender 4.0.

joint_scenes.zip

[merlinND]

Hello @paulalmasan,

As @jhoydis wasa saying, not all ITU materials are well-defined for all frequencies.
Here is where the "well-defined" check is performed:

sionna/sionna/rt/radio_material.py

Lines 279 to 287 in 0a4a22e

	@property
	def well_defined(self):
	"""bool : Get if the material is well-defined"""
	# pylint: disable=chained-comparison
	return ((self._conductivity >= 0.)
	and (self.relative_permittivity >= 1.)
	and (0. <= self.scattering_coefficient <= 1.)
	and (0. <= self.xpd_coefficient <= 1.)
	and (0. <= self.scattering_pattern.lambda_ <= 1.))

And here is where the medium_dry_ground material is defined (I believe):

sionna/sionna/rt/itu_materials.py

Lines 269 to 276 in 0a4a22e

	def medium_dry_ground_properties(f_hz):
	f_ghz = f_hz / 1e9
	if f_ghz < 1.0 or f_ghz > 10.0:
	return (-1.0, -1.0)
	relative_permittivity = 15.0*np.power(f_ghz, -0.1)
	conductivity = 0.035*np.power(f_ghz, 1.63)
	return (relative_permittivity, conductivity)

If you check that material's properties at the frequency that you are trying to simulate, you will likely find that it is not well-defined (please let us know if that's not the case).

[paulalmasan]

Thanks a lot @merlinND!! Your comment solved my issue with the "well-defined" materials. Indeed the problem was with the wrong frequency I was using instead of the material being "well-defined".