Possible PALS workflows

[danielkallendorf]

I would like to collect the possible pals workflows. Feel free to add any missing workflows, or comment with suggestions.
This discussion is related to Discussion 33

Main Workflow

The primary workflow, that has been frequently presented:

graph BT;

F@{ shape: lin-cyl, label: "XYZ.pals.format"  } <-->|PALS-Format| R[Reader/Writer];

subgraph "PALS Implementation"
R<-->|Keys/Values|T[Translator];
end

subgraph "Simulation Program"
T<-->|pals API| I[Interface Layer];
I-->App[Simulation];
App-->|"`updated 
parameters`"|I;
end

App--> Results

Loading

Conversion Workflow

This includes workflows like

graph LR;
F@{ shape: lin-cyl, label: "XYZ.pals.format1"  } -->|PALS-Format| R[Reader] 

subgraph "PALS Implementation"
R-->T[Translator] 
T-->W[Writer]
end
W -->|PALS-Format| F2@{ shape: lin-cyl, label: "XYZ.pals.format1"  };

Loading

Simulation Native to Pals

The simulation program has a native file format or API, which then should allow to write PALS-files through the interface layer and PALS API.

graph TB;
F@{ shape: lin-cyl, label: "file.app"  } --> App[Simulation];
A[Code] -->|"`Simulation
API`"| App[Simulation];

subgraph "Simulation Program"
App-->|"`updated 
parameters`"|I;
end

subgraph "PALS Implementation";
I[Interface Layer]-->|pals API| T[Translator];
T-->W[Writer];
end

W-->F2@{ shape: lin-cyl, label: "XYZ.pals.format" }

Loading

[danielkallendorf]

Database

There was a discussion to have a database connection instead of a file

graph BT;

F@{ shape: cyl, label: "Database"  } <-->|???| R[ORM];

subgraph "PALS Implementation"
R<-->T[Translator];
end

Loading

Can we define/generate a default DB-Schema?

[danielkallendorf]

Pals App-File Writer

Until all codes implement PALS (far future), we have to rely on input file writing (and output reading).

graph BT;
F@{ shape: lin-cyl, label: "XYZ.pals.format"  } <-->|PALS-Format| R[Reader/Writer];

subgraph "PALS Implementation"
R<-->T[Translator];
end

T<-->|pals API| C["`PALS-*-converter`"];
C-->F2@{ shape: lin-cyl, label: "file.app"  };


subgraph "Simulation Program"
F2-->App[Simulation];
end

App-->F3@{ shape: lin-cyl, label: "output.app"  };
F3-->C;

App--> Results

Loading

[danielkallendorf]

Using PALS without the translator?

Until the PALS-Implementeation for every required language exists, it should still be possible to utilize a PALS-implementation for other languages to handle all the validation and higher functions and to write it down into a more verbose pals file:

graph TB;
F@{ shape: lin-cyl, label: "XYZ.pals.format"  } -->|PALS-Format| R[Reader/Writer];

subgraph "PALS Implementation"
R-->T[Translator];
T-->|expanded|R;
end

R-->|PALS-Format|F2@{ shape: lin-cyl, label: "expanded.pals.format"  };
F2-->R2[Reader];

subgraph "Simulation Program"
R2-->|Keys/Values| I[Interface]
I-->App[Simulation];
end

Loading

In this workflow, directly editing the extended file is not advised. We might even enforce this with a checksum.

[ax3l]

I think the expanded format (so far described here) should create "simple" (flat) and "explicit" (no references) version. So in particular, we remove all inheritance (cross-references) and flatten the lattice.

For properties in PALS, like MatterP, I would like to keep it simple enough that there is not a lot of extra transformation needed to use it (e.g., as a human/machine). If looking up the period table from a string is above that threshold we need to decide for ourselves.

Do we have other use cases we can collect that are currently not sufficiently simple in the standard lattice (expanded or not)?

[DavidSagan]

This gets into the issue of what are input and what are computed (EG floor coordinate) parameters (Issue #107). I'm not sure what @ax3l means by "explicit". Certainly everything in the standard should be well defined. As for "simple", I think a better criterion would be what is useful but not to the extent that there are problems with maintenance/creation of the interfaces. One of the aims of the interface is to alleviate the needed for Users to reinvent the wheel. For the C++ interface, I will be looking into such things as integration with, for example, the std::atomic library to provide atomic parameters.

[ax3l]

With explicit I just mean no cross-references left (e.g., resolved inheritance to concrete parameters).

std::atomic in C++ is for coordinating parallel execution (eg. mutexes, sums in threaded environments, etc.). It does not provide physical constants.

[DavidSagan]

Yes scratch the mention to std::atomic.