[sverhoeven]

Refs #57

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.85%. Comparing base (8ca087f) to head (a6d7770).

Additional details and impacted files

@@             Coverage Diff              @@
##           maintenance      #65   +/-   ##
============================================
  Coverage        80.85%   80.85%           
============================================
  Files               52       52           
  Lines             2580     2580           
  Branches            27       27           
============================================
  Hits              2086     2086           
  Misses             491      491           
  Partials             3        3           

Flag	Coverage Δ
python	49.80% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
Python	49.80% <ø> (ø)
Julia	86.81% <ø> (ø)
R	96.68% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[BSchilperoort]

Can't we use a git symlink to not have duplicate files?

[sverhoeven]

Nope see #6

[BSchilperoort]

What apparently can work is a custom hook for hatchling;

w/ [tool.hatch.build.hooks.custom]

python/hatch_build.py::

from pathlib import Path

from hatchling.builders.hooks.plugin.interface import BuildHookInterface


class CustomBuildHook(BuildHookInterface):
    """Bundle the repository-wide openapi.yaml into the package."""

    def initialize(self, version, build_data):
        spec = Path(self.root).parent / "openapi.yaml"
        if not spec.exists():
            # Building from an sdist, which already contains the spec under src/
            return
        dest = "remotebmi/server/openapi.yaml"
        if self.target_name == "sdist":
            dest = f"src/{dest}"
        build_data["force_include"][str(spec)] = dest

and make_app in init.py needs:

    openapi_path = Path(__file__).parent / "openapi.yaml"
    if not openapi_path.exists():
        # Editable install, use spec from root of repository
        openapi_path = Path(__file__).parents[4] / "openapi.yaml"

But that's also not ideal.

[sverhoeven]

I (and llm) did something similar at https://github.com/haddocking/protein-detective/blob/b4cd0a2184416d91d5685761a9c5795eb9bb418e/hatch_build.py

I will put on the list to do

[BSchilperoort]

get_start_time and get_end_time are also of type float, and here the values -Inf and +Inf do make physical sense: if you have a model that does not depend on external inputs during the model run, and can be forwarded and reversed in time (negative time steps are allowed).

There are also get_current_time, update_until and get_time_step, as well as some grid functions that return double;

• get_grid_origin
• get_grid_spacing
• get_grid_x
• get_grid_y
• get_grid_z

However, there it is less physical to have nan/inf. Might as well support IEEE floats fully there though...

[sverhoeven]

get_start_time and get_end_time are also of type float, and here the values -Inf and +Inf do make physical sense: if you have a model that does not depend on external inputs during the model run, and can be forwarded and reversed in time (negative time steps are allowed).

There are also get_current_time, update_until and get_time_step, as well as some grid functions that return double;

• get_grid_origin
• get_grid_spacing
• get_grid_x
• get_grid_y
• get_grid_z

However, there it is less physical to have nan/inf. Might as well support IEEE floats fully there though...

Ok let us get clear what function should accept/return what:

1. Should None or null be an option besides number | "NaN" | "Infinity" | "-Infinity"? Or is NaN enough?
2. Should NaN be an option for update_until, get_current_time, get_start_time, get_end_time and get_time_step?
3. In grid functions do we want to keep format: double? If not then also integers are allowed.

In a6d7770 I picked no, no, yes.
That commit still has to be propagated to rest of stack at time of writing this comment.

[BSchilperoort]

Ok let us get clear what function should accept/return what:

IMO, for simplicity's sake we just use the IEEEDouble whenever the BMI spec says the return type or array type should be double. Handling what +/-Inf or NaN means there can be left to the frameworks using BMI.

Ideally RemoteBMI is as invisible is possible, even in these kinds of cases. Validation of a NaN value in a grid doesn't need to happen in RemoteBMI.

Should None or null be an option besides number | "NaN" | "Infinity" | "-Infinity"? Or is NaN enough?

None/null are not valid IEEE float values, so just having number, NaN, Inf and -Inf is sufficient.