Electric field monitor for Charge

[marc-flex]

Greptile Summary

Adds electric field monitoring capabilities to the Charge simulation module, enabling visualization and analysis of steady-state electric fields with support for both tetrahedral and triangular mesh grids.

• Added new SteadyElectricFieldMonitor class with Ex, Ey, Ez component monitoring and proper unit handling (V/μm)
• Implemented robust VTK file support with ignore_invalid_cells parameter and cell-to-point data conversion for better visualization
• Reorganized mesh-related documentation and APIs under a dedicated /mesh section for improved code organization
• Enhanced VolumeMesher with mesh refinement capabilities and grid validation for wave ports
• Improved boundary layer validation with new MIN_NUM_* constants and centralized warning system

[github-actions]

Diff Coverage

Diff: origin/develop...HEAD, staged and unstaged changes

• tidy3d/components/data/data_array.py (100%)
• tidy3d/components/data/unstructured/base.py (42.9%): Missing lines 632-634,636
• tidy3d/components/tcad/data/monitor_data/charge.py (100%)
• tidy3d/components/tcad/monitors/charge.py (100%)

Summary

• Total: 43 lines
• Missing: 4 lines
• Coverage: 90%

tidy3d/components/data/unstructured/base.py

  628         vtk_obj,
  629     ):
  630         """Get point data values from a VTK object."""
  631 
! 632         cellDataToPointData = vtk["mod"].vtkCellDataToPointData()
! 633         cellDataToPointData.SetInputData(vtk_obj)
! 634         cellDataToPointData.Update()
  635 
! 636         return cellDataToPointData.GetOutput()
  637 
  638     @classmethod
  639     @requires_vtk
  640     def _get_values_from_vtk(

---

[greptile-apps]

_{7 files reviewed, 4 comments
Edit PR Review Bot Settings | Greptile}

[dbochkov-flexcompute]

Looks good overall, but I wanted to discuss whether we should store Ex, Ey, and Ez separately or in a single Triangular/Tetrahedral-GridDataset. In FDTD field monitors we do store them separately, but I guess one big reason to do that there is that Ex, Ey, and Ez can live on different grids (in fact, it was default up until some point). Moreover, storing cartesian grid info typically doesn't require much memory in comparison to actual field data. For unstructured datasets storing grid info does actually take more memory that a single field, and it seems like at least in this PR Ex, Ey, and Ez are stored at the same locations. Do you see any other arguments towards storing them separately or as a single xarray?

In my surface monitor PR I decided to go the single-array route and use indexed data array with additional coord "axis" https://github.com/flexcompute/tidy3d/pull/2360/files#diff-834da9ec0c6f019fc8dde7c9b3cd1d2eafb780dadfadb21e94c0a313be526076R1256-R1285. One other smaller advantage is that it makes calculating the magnitude of vector field and producing a new unstructured dataset for that very straightforward

tidy3d/tidy3d/components/data/unstructured/base.py

Lines 410 to 412 in 2116575

	def norm(self, dim) -> UnstructuredDataset:
	"""Compute vector norm along a given dimension."""
	return self.updated_copy(values=np.sqrt(self.values.dot(self.values.conj(), dim=dim).real))

[marc-flex]

Yes, that makes sense! Will do that. Thanks @dbochkov-flexcompute

[marc-flex]

@dbochkov-flexcompute I just realized that we're already storing multiple solution in each of the Ex, Ey, Ez fields since it can have multiple voltages. Though currently it only stores one voltage in Conduction, it can store multiple in Charge. I'm wondering what approach we should follow here. Add another index to the data so that we have voltage and component?

[dbochkov-flexcompute]

@dbochkov-flexcompute I just realized that we're already storing multiple solution in each of the Ex, Ey, Ez fields since it can have multiple voltages. Though currently it only stores one voltage in Conduction, it can store multiple in Charge. I'm wondering what approach we should follow here. Add another index to the data so that we have voltage and component?

yeah, I think that would make sense

[marc-flex]

@dbochkov-flexcompute I updated this to use the same data array class you mentioned. There will probably be conflict when either this or your branch gets merged though but it should be pretty straightforward.

[momchil-flex]

Thanks. Minor comments, also wondering what is your plan for the related current density monitor?

[greptile-apps]

_{70 files reviewed, 2 comments
Edit PR Review Bot Settings | Greptile}