Requirements for generating Fluid Cube dataset about inductiva

[MariaLCastro]

I'll also emphasize that I'm not blocked by this in the dataset generation task. I already generated the dataset. These requirements were the output of a discussion I had with @luispcunha and @IvanPombo on how we could build a use-case of the API for generating the dataset.

That's why I don't think I should work to build the dataset generating the input files but I can start building the infrastructure without all these features and add them to the demo as they are implemented. WDYT?

[sarmento]

@MariaLCastro and @fabiocruz : what Hugo was saying -- and I fully support because that is the way to make progress faster -- is for Maria to start implementing the data generating script using the available classes (DamBreak or the GenericSplishSplash) and build the whole thing as if it was the "right class" with the "required features".

This way we can immediately get most of the final code done, even before having the required class, and put the pressure on the API. This is the most important thing. This will show us other aspects of the infra-structure that need to be fixed before we worry about the exact semantics of the dataset.

@MariaLCastro : please move fwd in terms of implementing a notebook where you get the basic structure of the data generation script working. Let's see what is going to break. That's what we are trying to speed up....

[fabiocruz]

This can easily be done after #167 is merged.

[hpenedones]

Thanks Maria, don't let this prevent you from making progress.
Can you re-write a version of your code using the API, where initially you don't have control over all those parameters, but only a subset of them?

[fabiocruz]

@MariaLCastro see this PR. It is possible to launch any simulation to run on the API now, given its input file(s). AFAIK this is the recommended way to operate with the API for advanced use cases, like generating the dataset.

[hpenedones]

Like Fábio said, some advanced use cases can be implemented with a lower-level call to the API that just passes config files, but here you are generating a dataset about a scenario (DamBreak) that we support in the more "high level" pre-packaged scenarios, so it makes sense to go through there. Don't go via the low level call. It is ok to make feature requests like you did here, I just commented to say: don't let it be a blocker for you to make progress, because you can write the initial code to generate a dataset via the api, with a smaller number of controllable parameters and add the remaining later, once they become available.

My comment was about "As a first requirement, for generating the dataset we need to be able to set all the variables needed to replicate the conditions in that script.", which putting a blocking dependency on another developer, when in fact there are ways to make progress even without that.

[fabiocruz]

[...] here you are generating a dataset about a scenario (DamBreak) that we support in the more "high level" pre-packaged scenarios, so it makes sense to go through there. Don't go via the low level call.

For discussion: where do we stop calling a scenario a "dam break" (and hence stop providing a high-level interface for it)?

AFAIK the dataset that @MariaLCastro is generating has a few features that clearly distinguish is from the dam break scenario, e.g. the high viscosity of the fluids, the initial velocity, the need to tune the CFL condition, the need to ignore particle sorting during the simulation, etc.

[MariaLCastro]

... , the need to ignore particle sorting during the simulation, etc.

Forgot to add this because it is still hard coded on the last dataset I generated. I'll add this to the list of requirements.

[IvanPombo]

Fabio is correct in sense of the scenarios, there is a lot of pre-canned stuffed for @MariaLCastro dataset. However, we can still provide access through the API without writing the config files. This is kind of what she is doing in local development.

The value is still to not worry about the infrastructure of all these and have speed-up inside the "server".

We can provide three-levels:

• High-level: Pre-canned scenarios that are well-defined and the parameters to be changed are fixed;
• Medium-level: Interface where the user can write its own scenario in a pythonic way;
• Low-level: Interface to send in the config files and let things run.

[MariaLCastro]

Started working on this today and notices that we can't yet pass a fluid with arbitrary viscosity and density without using the inductiva_sph package. One more requirement for the dataset:

• pass arbitrary viscosities using the Inductiva package

[MariaLCastro]

I'm reopening this issue because I recently opened this PR and noticed that some key features to run the dataset are no longer available.

I edited the features that are still missing in this issue. Do you plan to include them soon?