I recently ported code to precice 3 API. I noticed that hasData (along with hasMesh) was removed.
We found hasData useful. If hasData(var) gives true, we would read var from preCICE, otherwise use a provided data file or default value or something. We can disable coupling of a variable by removing it from the precice config and don’t need have our own config that needs to be changed. It was convenient to quickly try different setups, diagnose issues, without remembering to keep multiple configs in sync.
Is there an alternative we can use for this? We probably could use getDataDimension and catch the exception (I assume it throws? not clear from the documentation), but that feels wrong.
(I note that we may end up with an adapter config anyway for other reasons, so maybe this won’t matter. But even then this function could be useful, e.g. ignore the variable in the adapter config if it’s disabled in the precice config)
we typically have an adapter config, where we configure what data to read/write from/to the preCICE buffers. I would typically disable the data reading/writing at that level.
Would this approach not suffice for your use case?
Note that an adapter config can control several other aspects of the simulation, which is why we are requiring such a config in the ecosystem guidelines, and we are setting up a respective configuration schema.
There is nothing stopping us from adding an adapter config and it would work.
We were just thinking that for simple adapters (only one possible coupling interface, only a few variable who’s names can be identified by convention, etc.) only one config file (the precice config) might be easier to handle, no need to keep two configs in sync with redundant information.
I have had similar concerns a while ago, and we discussed the idea in this issue:
However, we have now decided to focus on auto-generating such kind of files, which so far have not been very complicated to handle in the adapters we know of.
The interoperability argument still holds: One could easily replace this simple adapter with a more complicated one in the future.
Also, I would not be surprised if this simple adapter soon needs to be more configurable, because the requirements change. One needs to plan ahead, and with the standard schema, this is easier.