Demo4paraview

[vasvav]

Purpose:
Demonstrate to new users how a VTU formatted file for Paraview is structured to output cell (agents) and grid (continuum) data. To run this demo, there is no requirement to install Paraview together with BioDynaMo. Also, to understand the driver function of this demo, users are advised to study the diffusion demo first.

Results:
Successful execution of the demo will produce four VTU files in the output/custom_paraview sub-folder that can be opened directly through Paraview. Files cells_4paraview.*.vtu (at two time steps) contain the results for all cells (agents) in the simulation, while files grid_4paraview.*.vtu (again at two time steps) contain the results for the two continuum (previously named diffusion grids) substances - in this example oxygen (O2) and some growth factor (GF) are considered as cytokines.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[TobiasDuswald]

Hi @vasvav ,

great initiative, I like the idea 💪 What do you think about slightly generalizing it? E.g. naming the demo custom-exporter and providing maybe one or two additional exports? Just something very simple, like exports to CSV, ROOT, or NumPy files?

If we went that way, we'd do the following:

• Write additional exporter (e.g. ROOT, CSV, NumPy)
• Each exporter should have a separate .h / .cc file such that if the user wants to reuse it, they can easily do so
• For the exporter we should add a post-scheduled op that is scheduled per iteration
• Add a README.md explaining that this is a demo for basic data exporters that are not optimized. The logic behind BDM's ParaView export is similar, but significantly more advanced, e.g. uses parallelization, compression, and supports the visualization of arbitrary agent attributes as specified via bdm.json. But if people want to write exports for their analysis outside of paraview, that's how they can do it. (In fact if users want to write some good exporters they are more then welcome to contribute them to the repository 🤩 )

Let me know what you think about that :)

---

some minor technicalities:

• the new files must have the licence header (i believe that's the case)
• the code needs to be formated with clang-format (e.g. via make format typed in your build folder)
• we shouldn't hard code output/export but rather use Simulation sim; sim.GetOutputDir()

[nicogno]

Hi @vasvav , I like the idea as well! :) As suggested by @TobiasDuswald , I think that generalising the demo to include multiple export formats and using TimeSeries (or operations) would make it more comprehensive and helpful for beginner users. Attached you can find the "evaluate.h" file that I've implemented for my alveoli simulation (inspired from a demo made by Lukas). Within it there's a bunch of functions that can be used to collect data from the agents and from the diffusion grids as well as export the data to CSV, txt and root files. In the main file you can set the frequency of the operation with

auto* scheduler = sim.GetScheduler();
auto* updatetimeseries_op = scheduler->GetOps("update time series")[0];
updatetimeseries_op->frequency_ = sparam->cell_number_freq;

To setup the result collection you can use

SetupResultCollection(&sim);

right after you've instantiated the sim object and plot the results at the end of the simulation with something like

std::vector<TimeSeries> results;
results.push_back(*sim.GetTimeSeries());
PlotResults(results, "output", AEC2_per_alv);

where AEC2_per_alv is a const std::map<int, int>& in this case, but you can adapt it to your needs.
Hope that helps :)
evaluate.h.zip

[vasvav]

Dear @nicogno and @TobiasDuswald, many thanks for the very useful suggestions and comments!

@TobiasDuswald, I agree with the generalisation of the "custom" exporter :) Sure, I can write up something for a CSV-formatted file, yet I am neither familiar with ROOT nor with NumPy therefore I don't think I can contribute in this. I think it goes without saying that I am very very happy if anyone wishes to chime in and add something in this direction.
Not 100% sure I understand what I need to do on... "we should add a post-scheduled op that is scheduled per iteration" - I'd love if we have a quick chat and explain the concept ;) Also, I do agree having a ReadMe.md describing the purpose and explaining these details you highlight.

@nicogno, I like the idea for allowing the "custom" exporter to manage for time-series data more elegantly. However, I'm thinking which is best to do in order to make the code accessible to inexperienced users ;) Would love you explain me the approach presented in the example code you shared with us- there are a few bits I am not entirely sure I follow.

[TobiasDuswald]

@vasvav I thought of something like this (https://biodynamo.org/notebooks/ST13-dynamic-scheduling.html) instead of calling a function after Simulate(). Then the export would run every simulation time step, e.g. 5 times for Simulate(5). Feel free to ping me on Discord if you want to discuss it.