Add particlefile_to_v3_zarr() helper - #2811
Conversation
Parquet metadata is parsed as bytes strings. This decodes them.
5d843b7 to
06f1d58
Compare
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
I thought that this would be useful for the future as well
There was a problem hiding this comment.
not sure about the name of this file (also on the name of test_v3.py)
There was a problem hiding this comment.
How about compatibility_v3.py? Or compat_v3.py? Or `regression_v3.py?
There was a problem hiding this comment.
compat_v3 sounds good
| df = pl.read_parquet(from_parquet) | ||
| table = pq.read_table(from_parquet) | ||
|
|
||
| # TODO: Check for available memory here and fail as a safeguard? |
There was a problem hiding this comment.
This is intentionally left here. I think it would be good to discuss (or leave for a future PR)
| return ret | ||
|
|
||
|
|
||
| def particlefile_to_v3_zarr(from_parquet: str | os.PathLike, to_zarr: str | os.PathLike) -> None: |
There was a problem hiding this comment.
I think this API (i.e., from file-> file) is significantly more stable and robust than trying to take in/return in-memory objects like dataframes or Xarray Datasets.
| for var in ["lat", "lon", "depth", "time"]: | ||
| assert var in ds.variables | ||
|
|
||
| assert set(ds.dims) == {"obs", "trajectory"} |
There was a problem hiding this comment.
I think that's it in terms of checks that we need to do? Do you have anything else in mind @erikvansebille ?
| def test_particlefile_to_v3_zarr(df): | ||
| with tempfile.TemporaryDirectory() as tmpdir: |
There was a problem hiding this comment.
Can't do
@given(df=pst.particlefile_output())
def test_particlefile_to_v3_zarr(df, tmp_zarr, tmp_parquet)since hypothesis doesn't allow mixing of strategies and Pytest fixtures
| Notes | ||
| ----- | ||
| This is not a lazy operation — the entire parquet file is read into memory | ||
| and pivoted before writing to zarr. For large particle files this may | ||
| require significant memory. Performance improvements are welcome via PRs. | ||
| """ |
There was a problem hiding this comment.
Notes
This is not a lazy operation — the entire parquet file is read into memory
and pivoted before writing to zarr. For large particle files this may
require significant memory. Performance improvements are welcome via PRs.
I think that this sort of functionality (i.e., pivoting dataframes to zarr CF convention output) can live outside of Parcels since its also relevant to other tools (e..g, TRACMASS).
@oj-tooth have you guys done any work around pivoting (larger than in-memory) tabular data into Lagrangian Zarr datasets?
There was a problem hiding this comment.
Maybe its something that we can collab on across-teams
erikvansebille
left a comment
There was a problem hiding this comment.
Looks good; a few comments/questions
There was a problem hiding this comment.
Also remove the TODO about the conversion function higher up in the notebook?
And remove "do" from the "We do also have some tooling ..."?
And filter out the ZarrUserWarning: Consolidated metadata is currently not part in the Zarr format 3 specification. It may not be supported by other zarr implementations and may change in the future.?
|
|
||
|
|
||
| def _generate_dummy_data(particle: ParticleClass, nparticles=10, nobs=10) -> pd.DataFrame: | ||
| """Build a pandera DataFrameSchema from a ParticleClass. |
There was a problem hiding this comment.
Type-o? Auto-correct? Or intentional?
| """Build a pandera DataFrameSchema from a ParticleClass. | |
| """Build a pandas DataFrameSchema from a ParticleClass. |
There was a problem hiding this comment.
This was left over from a different implementation I was exploring (using Panderas hypothesis strategies), though it wasn't as flexible as I was needing.
Cleaned up now
|
|
||
| Only variables with ``to_write=True`` are included in the schema. | ||
| Each column is typed with the variable's numpy dtype and carries the | ||
| variable's ``attrs`` as pandera column-level metadata. |
There was a problem hiding this comment.
| variable's ``attrs`` as pandera column-level metadata. | |
| variable's ``attrs`` as pandas column-level metadata. |
| from parcels._xarray import open_raw_zarr | ||
| from parcels._core.particleset import ParticleSet | ||
| from parcels._core.particlefile import ParticleFile, read_particlefile | ||
| from ._v3 import particlefile_to_v3_zarr |
There was a problem hiding this comment.
Are we at the risk of confusing users which 'v3' we mean here? Zarr v3? Parcels v3? Both? Should we clarify?
|
|
||
| Notes | ||
| ----- | ||
| This is not a lazy operation — the entire parquet file is read into memory |
There was a problem hiding this comment.
Would a relatively simple improvement be to do the loading/pivoting/writing on a per-variable basis? So that only one variable is kept in memory at a time? Or is this not worth the extra code/effort for now?
|
|
||
| Reads the parquet file, renames columns to v3 conventions | ||
| (``particle_id`` -> ``trajectory``, ``t`` -> ``time``, ``x`` -> ``lon``, | ||
| ``y`` -> ``lat``, ``z`` -> ``depth``), and reshapes the data into a 2D |
There was a problem hiding this comment.
Actually, the output was already z in v3
| ``y`` -> ``lat``, ``z`` -> ``depth``), and reshapes the data into a 2D | |
| ``y`` -> ``lat``), and reshapes the data into a 2D |
| # TODO: Check for available memory here and fail as a safeguard? | ||
|
|
||
| # Rename columns to v3 conventions | ||
| rename_map = {"particle_id": "trajectory", "t": "time", "x": "lon", "y": "lat", "z": "depth"} |
There was a problem hiding this comment.
| rename_map = {"particle_id": "trajectory", "t": "time", "x": "lon", "y": "lat", "z": "depth"} | |
| rename_map = {"particle_id": "trajectory", "t": "time", "x": "lon", "y": "lat"} |
There was a problem hiding this comment.
I was trying to implement the particlefile_to_v3_zarr() in #2812 (so that I could much easier compare the old v3 and the new v4 output), but ran into an issue when ow all trajectories have the same length (e.g. because some particles are deleted). This leads to a ragged pivot table and then all NaNs in the zarr file. Could you explore a fix, @VeckoTheGecko? Ragged output is quite normal in Parcels
Description
Adds particlefile_to_v3_zarr helper, tests, and strategies for property based testing.
Note that this function is eager. This is noted in the docstring for the function.
Checklist
mainfor normal development,v3-supportfor v3 support)AI Disclosure