piyushkarki commented 1 day ago

Current Architecture

The Tandem infrastructure currently relies on Lua files to define constants and functionalities for simulating specific scenarios. Each Lua file describes a class that encapsulates all required parameters and functions, including boundary conditions and analytical solutions. This modular approach allows for unique simulations with distinct parameters and boundary conditions.

Parsing Mechanism

Configuration: The parser reads the namespace of the scenario from a TOML file.
Lua File Identification: It identifies the "field," which corresponds to the Lua file name.
Scenario Extractors:
- For the static solver, the C++ files determine the simulation class type (e.g., elasticity problem or Poisson problem).
- Based on the type, it utilizes specific scenario extractors for each problem type.
- The extractor uses the Lua file specified in the configuration.

The scenario extractor/parser is defined in the corresponding header files (e.g., for elasticity or Poisson).

Proposed Enhancement: Python Parser

We aim to create a similar parser for Python scripts that can be integrated into the C++ source code. This enhancement will allow us to access values defined in Python scripts, leveraging Python's extensive capabilities.

Benefits of Using Python

As a new user/dev, I do not instantly see a benefit at the moment but I understand that having python as a scripting language can allow several general advantages like:

Library Ecosystem: Access to a vast array of Python libraries, expanding functionality.
Community Support: A larger community provides better debugging support and resources for resolving new or unseen issues.
Scripting Flexibility: Debatable since what I've seen of Lua is also quite easy to understand so it is actually up to how familiar you are with the particular language)

Next steps:

[x] Understand the parsing of lua file
[ ] Create a parallel implementation for the python parsing using pybind11 as suggested by Bar
[ ] Consider structural refactoring

piyushkarki commented 1 day ago

First of all, the parser exists here. But this only gets the config elements as a dictionary kind of. Then you can access various elements of the toml config file using a pointer notation like cfg->mesh_file or something like that.

The control flows through:

main -> ElasticityScenario ( which inherits from Scenario ) . I think it is necessary to modify the Scenario file to adopt python changes in order to function with a python script. Specifically, here you can see the where the loading of the file data is taking place. And the parsing of the specific lua file takes place at LuaLib.cpp.

We need to either mimic this pattern and just add a PythonLib.cpp or perhaps think of another way this could be done.

piyushkarki commented 9 hours ago

Lua to C++ Function Conversion in Scenario

Another crucial element is the lambda function defined in the Scenario. This function takes a function name and a container intended to hold this function. If the name exists in the Lua file, it somehow "converts" the Lua function into a C++ format and inserts it into the container.

Implementation Details

This pattern is followed for almost all elements within the Lua file, except for a few constants (which I will confirm). Essentially, it translates the Lua implementation into statically typed C++ code, complete with a return type and implementation.

Python Implementation

If we were to move to a Python implementation, we could install the scenario as a module and use its functions locally within the C++ workspace. The main consideration would be handling the return type of the Python function. Since Python doesn't have a fixed return type, we would need to:

Typecast the return values in the Python module function, or
Mimic the Lua approach by creating a parallel parser that generates C++ functions from Python functions.

Performance Considerations

A key question is: Would performance be significantly impacted if we simply imported the Python module? The constants would only be called once, along with the solution and its Jacobian. The primary concern would be the boundary conditions (BCs), which might need to be evaluated at each iteration or time step. However, I am not yet familiar with the specifics of this implementation. There may also be other functions that need to be called at each time step.

Boundary Conditions

Additionally, I have questions about the enforcement of boundary conditions. I do not see an explicit implementation for BC enforcement in the static case. Currently, my focus is solely on the static case.

baroryan commented 5 hours ago

Hey! I commented on the points you raised:

A key question is: Would performance be significantly impacted if we simply imported the Python module? The constants would only be called once, along with the solution and its Jacobian. The primary concern would be the boundary conditions (BCs), which might need to be evaluated at each iteration or time step.

in tandem, the boundary function is called every timestep, so it can lead to slower run times. It needs to be tested through.

The main consideration would be handling the return type of the Python function. Since Python doesn't have a fixed return type

I think that in my implementation, I had a function that checks what Python returns and handles it . It either throws an error or converts list/numpy arrays/scalars to something that C++ can handle.