# Alternative for hasData **URL:** \ **Category:** Using preCICE\ **Created:** [November 11, 2024, 5:10pm UTC](https://precice.discourse.group/t/alternative-for-hasdata/2211 "2024-11-11T17:10:17Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dabele](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/dabele/32/1919_2.png) [@dabele](https://precice.discourse.group/u/dabele)\ **Post date:** [November 11, 2024, 5:10pm UTC](https://precice.discourse.group/t/alternative-for-hasdata/2211/1 "2024-11-11T17:10:17Z")
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) ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [March 23, 2025, 3:41pm UTC](https://precice.discourse.group/t/alternative-for-hasdata/2211/2 "2025-03-23T15:41:51Z")
Dear @dabele, 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. ---
**Author:** ![dabele](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/dabele/32/1919_2.png) [@dabele](https://precice.discourse.group/u/dabele)\ **Post date:** [March 31, 2025, 5:39pm UTC](https://precice.discourse.group/t/alternative-for-hasdata/2211/3 "2025-03-31T17:39:01Z")
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. ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [April 1, 2025, 6:53am UTC](https://precice.discourse.group/t/alternative-for-hasdata/2211/4 "2025-04-01T06:53:22Z")
> [@dabele](#): > > 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: > > > \# Problem > > At the moment, there are options that need to be set both in the pr…eCICE configuration file and in every adapter's configuration file, in exactly the same way. > > This duplication can lead to errors, requires more checks from preCICE/adapters and reduces usability. Even if the user should understand what she is doing, she should not need to adapt to our technical complexity, but we should make the system more tight and less complex. > > \# An example > > Let's look at an example: the OpenFOAM-OpenFOAM CHT tutorial with nearest-projection mapping. In the Fluid participant, we set: > > https://github.com/precice/openfoam-adapter/blob/88dfbbae21a0dbdc9f21357a2a1d5d1954646a61/tutorials/CHT/flow-over-plate/buoyantPimpleFoam-laplacianFoam\_nearest-projection/Fluid/precice-adapter-config.yml#L5-L17 > > The \`read-data\` and \`write-data\` are also already known to preCICE, as they are set in the configuration file: > > https://github.com/precice/openfoam-adapter/blob/88dfbbae21a0dbdc9f21357a2a1d5d1954646a61/tutorials/CHT/flow-over-plate/buoyantPimpleFoam-laplacianFoam\_nearest-projection/precice-config\_serial.xml#L31-L36 > > Ideally, we could directly get groups of parameters, such as: {mesh, read/write, data name}. Although we still need to associate each solver interface with a part of the preCICE configuration file. As soon as this association is established, there should be no duplication. > > Moreover, the \`provideMeshConnectivity\` boolean is a technical thing that the user should not need to know about, as preCICE knows if it needs it. This is described in issue #467. As I wrote on the same issue: > \> I actually like this idea also for consistency with the high-level API idea. For example, the user does not need to configure an adapter to keep checkpoints when asking for implicit coupling. It's rather the adapter that asks preCICE if this is needed. Why not do the same here? > > This is also related to #311, in the sense that we duplicate information that preCICE already knows. > > \# Potential solution > > Implent additional methods in the API, which return what a participant should read/write on which mesh and which interface. 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.