BMI - getters and setters for logical and string types

[pya]

Is your feature request related to a problem? Please describe.

Currently, the BMI interface in mf6bmi.f90 implements getters and setters for int, float, and double. The types logical and string are not supported, yet. It would be very good to be able to access and modify values for these two data types.

Describe the solution you'd like

These functions should be exposed via BMI:

• get_value_double_logical
• get_value_double_ptr_logical
• set_value_double_logical
• get_value_double_string
• get_value_double_ptr_string
• set_value_double_string

The shape and rank should be handled analogous to int and double data types, as logical and string can also be in arrays.

Describe alternatives you've considered

There is no good alternative.

Additional context

I tested this with xmipy version 1.1 on the example Tidal.

The method mf6.get_input_var_names (where mf6 is an instance of XmiWrapper for the example Tidal) returns 677 names.
Using mf6.get_value_ptr with all these names throws either an xmipy.errors.InputError or an xmipy.errors.XMIError for some names.

Sorting out the errors by type:

values = {}
input_errs = {}
xmi_errors = {}
for name in mf6.get_input_var_names():
    try:
        values[name] = mf6.get_value_ptr(name)
    except InputError as err:
        input_errs[name] = err
    except XMIError as err:
        xmi_errors[name] = err

Gives 37 problems:

>>> len(input_errs)
11
>>> len(xmi_errors)
26

The InputErrors are all due to not recognized logical values:

>>> {mf6.get_var_type(name) for name in input_errs}
{'LOGICAL'}

The XMIErrors are all (the INTEGER must be another problem) due to not recognized string values:

>>> {mf6.get_var_type(name) for name in xmi_errors}
{'INTEGER (1)',
 'STRING LEN=16 (0)',
 'STRING LEN=16 (1)',
 'STRING LEN=16 (3)',
 'STRING LEN=33',
 'STRING LEN=40 (0)',
 'STRING LEN=40 (20)',
 'STRING LEN=40 (30)',
 'STRING LEN=40 (5)',
 'STRING LEN=40 (84)',
 'STRING LEN=500'}

One might argue that changing the values of logical and string is not important. Counterarguments are:

• Reading these values can be very valuable.
• When reading functions exit, writing functions should also be there for completeness.
• Switching a logical value can be very useful.
• Even changing string values may be of use.
• All data types should be handled in the same way.

[langevin-usgs]

Nice feature request, @pya. This is related to #856. Supporting a single string and a logical value should be possible through BMI, but there are some issues with supporting an array of strings. We are working on it.

[pya]

I see your problem. Would "practicality beats purity" work here? How about:

1. Make string scalars available in the same ways as other scalars.
2. Expose arrays of strings as arrays of characters with LEN=1. This means the rank would be one higher than it actually is. For example, instead of a one-dimensional array of strings, a two-dimensional array of characters of with LEN=1 would be exposed.

Clients such as xmipy can take care of turning the arrays of characters back to an arrays of strings with a lower rank. So, the user would see the "right thing" and xmipy does the appropriate translations in both directions. Would this work? Does the increased-by-one rank be a problem in other contexts? Does this violate the BMI specification?

This approach is pretty ugly. But putting on enough makeup could hide this ugliness, or not?

[pya]

@langevin-usgs Does my suggestion address the (right) problem? If so, would this be a viable approach?

[langevin-usgs]

Hey Mike, we will plan to take a look at this over the next couple weeks or hopefully sooner. Many of us have been out lately, but things should start picking back up. We were hoping the gfortran bug described in #987 would have been fixed by now as it is relevant to this request, but it looks like it's still open. Supporting string scalars shouldn't be a problem, and I think we can handle string arrays using some sort of trick, like you suggest, but having the gfortran fix would make the string arrays much easier to support.

[pya]

A compiler bug is a real showstopper. :( Let's hope it gets fixed soon. Let me know when you have a version that supports string and logical. Then I can help and write some xmipy-based tests.

[mjr-deltares]

Hi @pya, as @langevin-usgs said, we are currently looking into this issue. Our current view is that we are not likely to support pointer access to strings and arrays of strings through the API. So, the function get_value_ptr_string will not likely be implemented. However, we would then still have get_value_string to copy a string or an array of strings from MODFLOW into pre-allocated memory.

Are there scenarios you foresee that would require to have pointer-access to strings in MODFLOW, or is the proposed solution sufficient to your needs as well?

[langevin-usgs]

Hey @pya, we have added support for accessing strings through the API (both on the MODFLOW side and the xmipy side). You can only obtain a copy of strings; there is no way to set them. We also haven't done anything yet with logicals. If there is a use case that requires the ability to access logicals, then we can possibly implement something. Let us know if and how the capability to set strings and work with logicals is critical for your applications and we can consider further development.

[pya]

Great. I will have a look at it. Regarding the use cases for setting of string values and working with logicals, I don't have use cases right now. But experience shows that there always will be "creative" users who will find legitimate uses for such features. I think in the long run supporting the full BMI interface, i.e. read and write access to all types of variables, should be the goal. @langevin-usgs What do you think about this?

I have an upcoming project in which we we will implement new uses of the API. I anticipate that we will find interesting uses cases that need these features.