Skip to content

Read single precision fluid field in RAMSES#5207

Open
AnatoleStorck wants to merge 16 commits intoyt-project:mainfrom
AnatoleStorck:read_single_precision_fluid_field
Open

Read single precision fluid field in RAMSES#5207
AnatoleStorck wants to merge 16 commits intoyt-project:mainfrom
AnatoleStorck:read_single_precision_fluid_field

Conversation

@AnatoleStorck
Copy link
Contributor

@AnatoleStorck AnatoleStorck commented Jul 16, 2025

PR Summary

The current back-end for reading RAMSES fluid fields assumes the data is double precision. This PR (in collaboration with @cphyc ) is an initial expansion of the RAMSES fluid reader to read single precision fields. For my simulations, the RT fields are written in single precision so this change is needed to read them in.

PR Checklist

  • New features are documented, with docstrings and narrative docs
  • Adds a test for any bugs fixed. Adds tests for new features.

@welcome
Copy link

welcome bot commented Jul 16, 2025

Hi! Welcome, and thanks for opening this pull request. We have some guidelines for new pull requests, and soon you'll hear back about the results of our tests and continuous integration checks. Thank you for your contribution!

@chrishavlin chrishavlin added this to the 4.5.0 milestone Nov 14, 2025
@cphyc
Copy link
Member

cphyc commented Nov 21, 2025

For reviewers: testing is complicated as all the RAMSES datasets at hand are stored in double precision!

Copy link
Contributor

@chrishavlin chrishavlin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! left some minor coding style comments...

fields = [ "Potential,f", "Potential-old,f", "x-acceleration,f", "y-acceleration,f", "z-acceleration,f" ]

Importantly, the order of the fields should match the order in which they are written in the RAMSES output files.
yt will also assume that each entry is formed of a field name followed by its type (``f`` for single precision, ``d`` for double precision), separated by a comma. Field names containing commas are not supported, other precisions (e.g. integers) are not supported either. All fields in a given file type (gravity, hydro, ...) need to have the same precision.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it worth a mention that though yt can read in the single precision case, they will be converted to double precision for use within yt?

DETECTED_FIELDS = {} # type: ignore


def check_field_precision(fields: list[tuple[str, str]]) -> bool:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this function will only ever return True or throw an error (i.e., it will never return False), I'd suggest changing it a bit. Rename it to validate_field_precision and remove the bool returns.

bool
True if all fields have the same precision, False otherwise.
"""
if not fields:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you're using this to check for a list of length 0, can you change this to check for len(fields) == 0 explicitly? if fields can actually be None, then the typing should be updated to list[tuple[str, str]] | None.

if all fields are single precision, False if double precision.
"""
field_names = [field for field, _ in fields]
check_field_precision(fields)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh hey, you're already ignoring the output bool.

# Case 2: fields are provided by users in the config
fields = cls.load_fields_from_yt_config()
ok = len(fields) > 0
# Are fields are provided by users in the config?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# Are fields are provided by users in the config?
# Are fields provided by users in the config?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants