PrincetonUniversity / EDIPIC-2D

GNU General Public License v3.0
34 stars 20 forks source link

[Feature request] Better parameters input interface #17

Open HuntFeng opened 7 months ago

HuntFeng commented 7 months ago

High-level programming language as interface for inputting parameters

Currently, the input parameters are being read from text files init_<some_params>.dat. I think we should use a high-level programming language such as Python or Julia as a better parameter input interface, the init_<some_params>.dat files can be generated by this new interface.

Illustration

Here are few liens of Python code to illustrate my idea.

Users could define a simulation instantiating a Simulation class

# python code to define a simulation with RZ coordinate system
from boundary import Boundary

simulation = Simulation(coordinate="RZ")

Users could instantiate classes in Python to define boundary objects

# python code to define boundaries
from boundary import Boundary

...
boundary1 = Boundary(lower_index=[0, 0], upper_index=[0, 64], boundary_type="metal")
boundary2 = Boundary(lower_index=[0, 64], upper_index=[64, 32], boundary_type="metal")
boundary3 = Boundary(lower_index=[32, 0], upper_index=[32, 64], boundary_type="metal")
boundary4 = Boundary(lower_index=[0, 0], upper_index=[32, 0], boundary_type="metal")
...

By default, each boundary is associated with some default metal material. It is up to user to further define the parameters of the metal.

from boundary import Boundary
from material import Material

...
metal = Material()
metal.set_potential(100) # unit: V
boundary1 = Boundary(lower_index=[0, 0], upper_index=[0, 64], boundary_type="metal")
# user is able to further define materials if they want to
boundary1.set_material(metal)
...

Benefits

There are several benefits using this new interface for inputting parameters.

  1. This approach hides the unnecessary complexity from users. In the current implementation of EDIPIC-2D, users will have to go through at least 3 files, parameter description, init_configuration.dat and init_bo.dat (sometimes even 4 files if user needs to customize boundary material). It is a bit overwhelming compare to the illustration shown above.
  2. The new interface reduces the string parsing error. In the current implementation the parameters are being read from the text files, any invalid characters, spaces, or empty lines in the text files can crash the simulation easily. By utilizing the string parsing libraries in the high-level programming language, we guarantee the format of the input files are absolutely correct.
  3. Having high-level programming language as an interface can leverage the language features supported by all modern code editors. Modern code editors supports autocomplete, error-checking (diagnostics), jump-to-definition, and many other language features. Users can easily programed a simulation with the help of autocomplete, and debug the code by error-checking. It is impossible to do this with the text files.
  4. The input interface I shown above is commonly used in other industrial softwares such as Ansys, Comsol, Unity, and more. It would be beneficial to have such interface implemented if similar software is planed to develop based on EDIPIC-2D.
stephethier commented 7 months ago

Dear Hunt Feng,

Thank you for the suggestion. I have been working on a new version of the input interface using Fortran namelists. There will be a single input file containing different sections (namelists). This is part of the Fortran standard and is very flexible, avoiding a lot of the issues that you brought up (parameters don't have to be in order, there is no strict format for the numbers, no need to specify a parameter if using the default value set in the code, etc.).

I have started implementing it, and just need to find the time to complete it.

Regards, Stephane

HuntFeng commented 7 months ago

Dear Hunt Feng,

Thank you for the suggestion. I have been working on a new version of the input interface using Fortran namelists. There will be a single input file containing different sections (namelists). This is part of the Fortran standard and is very flexible, avoiding a lot of the issues that you brought up (parameters don't have to be in order, there is no strict format for the numbers, no need to specify a parameter if using the default value set in the code, etc.).

I have started implementing it, and just need to find the time to complete it.

Regards,

Stephane

Thanks for the hard work! This is a good approach! I look forward to using it in the future.