WIP: TOML Parameters by c-prather · Pull Request #1277 · parthenon-hpc-lab/parthenon

c-prather · 2025-07-01T18:47:27Z

PR Summary

This started at the meeting as a method of addressing a number of different issues related to parameter parsing and storage.

It adds toml++ as a dependency managing parameter parsing and storage (in nested toml::table objects representing arbitrarily-nested versions of the old parameter "blocks"). Thus new Parthenon input files can either be in TOML as well as in the old input format.

Unfortunately, turning the very loose Athena/Parthenon input language into a strict standard meant confronting types. In the old parameters, everything was a string until it was used by the code (meaning, among other hilarities, the same parameter could get read as boolean and string in the same code, and single-element lists had zero distinguishing features from a string).

toml++ stores variables with a limited set of types conforming to the TOML standard, so there is now a concept of "right" and "wrong" type with which to fetch something. Thus, for example, .true. is no longer a valid boolean evaluating to false. However, this may break features which relied on ambiguity: for example in Parthenon, one parameter allowed strings "true" "false" and "timestamp" as valid inputs -- as the one who wrote that input I can say with confidence that nonsense was bad and it's good that it's now impossible. Incidentally parthenon/job/archive_parameters=timestamp is now expressed parthenon/job/archive_parameters=true and parthenon/job/archive_timestamp=true.

All that to say backward compatibility is best-effort, though it works perfectly for the tests.

The new system comes with a number of advantages. As noted, "blocks" (tables) can now be nested arbitrarily, and iteration within a table is local. Thus within Parthenon one could call pinput->Blocks("parthenon") to get the tables under keys "job", "output0", "time", and so on and so forth, each of which may define sub-tables similarly iterable. For more complex recursive tasks involving parameters of different types, toml::table defines a visitor for_each, examples of which can be found in parameter_input.hpp.

Parameters now have canonical paths "block1.block2.name" which can always be used to get them. There are now generic Get<T>("block", "name") and GetPath<T>("block1.block2.name") implementations for getting parameters beyond just int, Real, and vector -- these can be used to write and read your own parameters of any type, e.g. your own toml::tables, as well as for arrays which might contain multiple types (no idea why you'd actually do the latter, but it's allowed in the standard for some reason).

Additionally, the origin of each parameter is tracked in a table parallel to the parameters themselves, containing only strings. Calling GetOrigin("path") tells you what set a parameter, between { restart, input, cmdline, code, defaultvalue }. GetOriginFile gives you which input file set the parameter, if it was an input file. The loop processing multiple input files is WIP still but everything else is in place to pass as many -i file1.par -i file2.par etc. as you want.

Repeats are now checked within a single source (restart, input file) but not between sources. That is, an input file with block/var = x and later block/var = y will error, but if the former is defined in a restart file and overridden with an input, or overridden on the command line, that is expected. Though, you can optionally warn on all overridden parameters in case this is desirable behavior.

I think that's it for new features, except that the file reading is mildly simplified and hashing is simpler than it was, while maintaining (I think) exactly the same properties (not dependent on order parameters were added, but still dependent on all keys and values).

Code compatibility should be drop-in, all of the same function calls work the same as before, except anything relying on type ambiguities as mentioned above. The one exception is when iterating over blocks looking for a pattern. Examples of the replacement pattern for iterating over blocks can be found in the updated mesh.cpp and output_package.cpp.

This is very much still WIP, comments welcome.

Current TODO list:

GetAllPaths call to retrieve all leaf elements' full paths, for whenever Parthenon needs every parameter with a unique associated key
Either expand the parameter_lists_ store into a feature (i.e. retrieving "how did the restart file set this parameter, even though the new input file overrode it?") or ditch it.
Fix behavior on current tests
Lots of cleanup of debugging outputs and cruft, move some implementations out of the class header, etc.
Validation step on toml::parse results which explicitly forbids dates, mixed arrays, or optionally enforces the old two-layer block/var structure of tables.
Keep track of original parameter ordering, for in-order compilation
Make Blocks() return only toml::table even if there are other top-level values
Downstream testing to ensure backward compatibility
Documentation: new format, new calls, iteration convention, archive_parameters parameter change.

And write new tests of:

Parsing a TOML parameter file
Properly rejecting TOML bits we don't support in a TOML input file

PR Checklist

…into blb/toml

…b/toml

Yurlungur

Thanks for your hard work on this @bprather ! It seems like it was a lot harder to get right than you had hoped.

It also seems like you've combined a LOT of things in this MR. The simple TOML++ replacement has been mixed in with additional features. Perhaps these should be split up? For example, do the TOML overhaul in one MR and then the multiple input files + Providence tracking in a separate MR? They seem separable. That would help me at least read through this MR and provide useful feedback. I think it would also make it easier to discuss all the stuff you want to add here.

Also given you based this on my MR #1266, the diff will probably look cleaner if you merge into that branch, rather than develop.

However, this may break features which relied on ambiguity: for example in Parthenon, one parameter allowed strings "true" "false" and "timestamp" as valid inputs -- as the one who wrote that input I can say with confidence that nonsense was bad and it's good that it's now impossible.

I am fine paying this price. You're right that the original version was not great.

The new system comes with a number of advantages. As noted, "blocks" (tables) can now be nested arbitrarily, and iteration within a table is local. Thus within Parthenon one could call pinput->Blocks("parthenon") to get the tables under keys "job", "output0", "time", and so on and so forth, each of which may define sub-tables similarly iterable.

I can see the advantage to this but I honestly don't like it. It introduces a lot of extra complexity compared to a "flat" two-level structure. That said if that's how TOML works and we want to move to TOML, maybe that's the price we pay.

Parameters now have canonical paths

👍

as well as for arrays which might contain multiple types (no idea why you'd actually do the latter, but it's allowed in the standard for some reason).

I think we should explicitly forbid this. We're not Python.

Additionally, the origin of each parameter is tracked in a table parallel to the parameters themselves, containing only strings. Calling GetOrigin("path") tells you what set a parameter, between { restart, input, cmdline, code, defaultvalue }. GetOriginFile gives you which input file set the parameter, if it was an input file. The loop processing multiple input files is WIP still but everything else is in place to pass as many -i file1.par -i file2.par etc. as you want.

This is cool, but is there a reason to do it with a parallel TOML table? Wouldn't a std::map<std::string, ParameterOrigin> be better? Also I dunno how I feel about allowing multiple input files... I guess I'm worried that this seems like a lot of additional complexity for something that can, fundamentally, be solved with the unix cat utility.

That is, an input file with block/var = x and later block/var = y will error, but if the former is defined in a restart file and overridden with an input, or overridden on the command line, that is expected.

👍

What about two separate input files? That probably should error.

Code compatibility should be drop-in, all of the same function calls work the same as before, except anything relying on type ambiguities as mentioned above. The one exception is when iterating over blocks looking for a pattern. Examples of the replacement pattern for iterating over blocks can be found in the updated mesh.cpp and output_package.cpp.

👍

Yurlungur · 2025-07-01T19:45:06Z

    endif()
  endif()
 endif()
+include_directories("external/tomlplusplus")


Is this the preferred way to do it? Not add_subdirectory? How does this work for installing parthenon as a library?

It's header only, so I assumed this was how to do it. But there are a ton of installation methods on the website, maybe another works better? Didn't really think about this.

I would do add_subdirectory and then add TOML as a CMake target, the same way we add Kokkos. That should automatically thread it through all of the nonsense CMake might rely on.

The website doesn't explicitly call that approach out, but I see the cmake supports it. There's checks about whether or not the project is "top level."

Ok I tried messing with this a bit and it doesn't seem like TOML++'s build system supports this. So we should leave it for now and I'll submit an issue.

Yurlungur · 2025-07-01T19:50:28Z

+  for (auto pib : pin->Blocks("parthenon")) {
+    std::string block_name = std::string(pib.first);


Just to confirm, you could have instead done a search for "parthenon/static_refinement" here right? You just chose to use the nested block structure?

Actually, not really. Asking for Blocks("") would give you just "parthenon" and e.g. "problem" or whatever. If you need a multi-level recursive list you're encouraged into the visitor pattern.

hmm I don't love that... oh well... price we pay maybe.

Why is this a price? I thought separating Parthenon blocks was the whole reason for naming them all parthenon/ in the first place -- this just enforces that structure.
I can't think why anyone would name their blocks as if they had a structure, then want to iterate as if that structure weren't there, but if there's a use case it's definitely possible to emulate. Just didn't see it as useful.

I just want the ability to loop over all blocks, which is something someone might want to do. But if you've added a visitor that visits everything, then it's a non-issue.

Yurlungur · 2025-07-01T19:55:45Z

      "is undefined behavior. If you don't know how this was triggered, please contact "
      "the Parthenon developers.");
  pinput->SetBoolean("parthenon/job", "run_only_analysis", arg.analysis_flag);
+  pinput->ParameterDump(std::cerr);


didn't know this was possible, neat. Wonder if we should have a flag for that. Just spit out everything from all sources. If we're going to allow a bazillion of them, it would be nice to have parthenon combine them into a single "master" object we could read telling us exactly how the simulation was set up. (though I guess this gets dumped to restart)

But probably this should be guarded behind a flag, right?

Happy to write any of that!

Yurlungur · 2025-07-01T20:20:24Z

+        v.erase(std::remove(v.begin(), v.end(), ' '), v.end());
+        v.erase(std::remove(v.begin(), v.end(), '\''), v.end());
+        // std::cerr << "INSERTING: " << path << "=" << v << std::endl;
+        if (std::count(v.begin(), v.end(), ',')) {
+          // Record an array by adding the necessary TOML
+          try {
+            v = std::regex_replace(v, std::regex(","), ", ");
+            new_tbl = toml::parse(path + " = [" + v + "]");
+          } catch (const toml::parse_error &err) {
+            v = std::regex_replace(v, std::regex(", "), "\", \"");
+            new_tbl = toml::parse(path + " = [\"" + v + "\"]");
+          }


what joys maintaining backwards compatibility is...

Yurlungur · 2025-07-01T20:23:06Z

+  inline void recursive_merge(toml::table &a, const toml::table &b, const toml::key &key,
+                              T &&el, bool check_dups) {


I'm kind of disappointed by how much work you have to do to do this with TOML. It really feels like this should be functionality the library provides. In the end I don't think we're going down LOC in our parser. I was really hoping we would. To me that was part of the value proposition.

I was disappointed, too. Partially this was a consequence of using nested toml::tables as the data store, and not something with more features. Maybe something like std::map<std::string, std::variant<double, int64_t, etc, etc>> would work, and would implement some of these things for us.

Yeah.. or std::map<std::string, std::any>?

Well now that you pared this MR down to just the TOML port, it looks like we are way down in LOC so I am back to happy about that. But still, yeah, disappointing TOML doesn't provide a merge table feature.

Yurlungur · 2025-07-01T20:25:14Z

very satisfying to see all the red in this file!

Yurlungur · 2025-07-01T20:28:19Z

very satisfying to see all the red in this file!

c-prather · 2025-07-01T21:10:07Z

I am happy to rip out the origin tracking for now and make this a smaller changeset if that's preferred! It's only this way right now because I was developing the changes and features together a bit, to make sure the library was capable of doing the things I wanted, which it often seemed like it was not.

Re: nesting blocks, I think that's the biggest added complexity and source of possible bugs here. I am looking forward to having it available: for example, several of my blocks deal with corrections to a simulation, and each takes a list of "floors" describing when to trigger the fix, written in the same basic form. Having these as sub-blocks, rather than alongside other parameters at the root level, would mean I could finally enforce one base-level block per package and every package reads only its block, which would be nice for separability.

I am happy to optionally enforce the old two-level form: it would only require nixing the current replacement '/'->'.', then writing a check of the parsed table. But a check wouldn't solve the need to code for nested tables in Parthenon. The recursive visitor thing going on in parameter_input.hpp seems to work fine, but if it turns out to be buggy or need maintenance, or if we're writing a bunch more visitors, that obviously sucks. toml::table itself doesn't seem to offer any of this, which is disappointing, but maybe I missed some feature that would make our lives easier?

Re: multi-type lists, agreed. You already can't work with them (e.g. GetVector won't work) so they would just cause confusing type errors. I'm writing a little recursive walk of each newly-parsed table, looking for things TOML might allow but we don't: so far that's multi-type arrays, and possibly/optionally n == 2 table levels. I think that should also include any dates/times, as it seems like good practice to keep those out of parameter files and I could see a chance that things intended as strings get mis-parsed as dates and cause puzzling errors.

Re: the origins table, I was planning to write it out to restart files, so I wanted the serialization. But a map might be better, and now I'm not sure this info should be written to restarts... A map to the ParameterOrigin enum (rather than strings) would mean I'd need to unroll my hack storing origin filenames in the same field (maybe that's good though?). I think between provenance and orphan detection we should share one "shadow table," and I'm indifferent to what structure it is or how it's implemented so long as it does the thing.

Re: two input files, you're right but I hate it, because we're going to have to merge all the input files' parameters and error on overrides (by default), before we then merge them to the restart file parameters and don't check for overrides (by default). And of course we can't override those defaults without parsing the parameters first...

Yurlungur · 2025-07-01T21:59:04Z

I am happy to rip out the origin tracking for now and make this a smaller changeset if that's preferred! It's only this way right now because I was developing the changes and features together a bit, to make sure the library was capable of doing the things I wanted, which it often seemed like it was not.

Sounds good... yeah lets split it up into smaller units of work. I think future us will thank us.

Re: nesting blocks, I think that's the biggest added complexity and source of possible bugs here. I am looking forward to having it available: for example, several of my blocks deal with corrections to a simulation, and each takes a list of "floors" describing when to trigger the fix, written in the same basic form. Having these as sub-blocks, rather than alongside other parameters at the root level, would mean I could finally enforce one base-level block per package and every package reads only its block, which would be nice for separability.

If this is something you think you need downstream then so be it... Parthenon exists to support downstream codes. Do other downstream codes want this? @acreyes @adamdempsey90 @pdmullen @jdolence @pgrete ?

I am happy to optionally enforce the old two-level form: it would only require nixing the current replacement '/'->'.', then writing a check of the parsed table. But a check wouldn't solve the need to code for nested tables in Parthenon. The recursive visitor thing going on in parameter_input.hpp seems to work fine, but if it turns out to be buggy or need maintenance, or if we're writing a bunch more visitors, that obviously sucks. toml::table itself doesn't seem to offer any of this, which is disappointing, but maybe I missed some feature that would make our lives easier?

Given this is built into TOML I'm not sure us enforcing it buys us anything. It also becomes a non-issue if the a visit_all function exists, which it seems like you added. I think we can assume for now your visit all is fine and move on for now.

I'm writing a little recursive walk of each newly-parsed table, looking for things TOML might allow but we don't: so far that's multi-type arrays, and possibly/optionally n == 2 table levels. I think that should also include any dates/times, as it seems like good practice to keep those out of parameter files and I could see a chance that things intended as strings get mis-parsed as dates and cause puzzling errors.

👍 sounds good

Re: the origins table, I was planning to write it out to restart files, so I wanted the serialization. But a map might be better, and now I'm not sure this info should be written to restarts... A map to the ParameterOrigin enum (rather than strings) would mean I'd need to unroll my hack storing origin filenames in the same field (maybe that's good though?). I think between provenance and orphan detection we should share one "shadow table," and I'm indifferent to what structure it is or how it's implemented so long as it does the thing.

Ok let's table the provenance question for now. I can try to add the capability you wanted, now that I understand it, based on what you have here and what I was doing for docstrings in my MR. I agree provenance + docstring checking is kind of a single unit of functionality under the hood.

Re: two input files, you're right but I hate it, because we're going to have to merge all the input files' parameters and error on overrides (by default), before we then merge them to the restart file parameters and don't check for overrides (by default). And of course we can't override those defaults without parsing the parameters first...

I know but I think if we want multiple input files we absolutely have to check for duplicate parameters because that's the most likely source of errors, IMO... duplicate parameters running around in multiple copy-pasted files.

adamdempsey90 · 2025-07-01T22:29:22Z

My only comment right now is to please add a cmake compile time option to use the old parser without any modifications. Downstream codes should be able to opt in to this breaking change.

c-prather · 2025-07-01T22:30:21Z

Okay, all "shadow table" functionality related to origins is ripped out, though I left the interface stuff since it reflects what I think are the minimum distinctions to keep.

Also tabling multiple input files until origin info is restored -- I absolutely agree checking for duplicate params between input files is necessary, but it sucks to implement and I think it will depend on how the origin information is eventually kept. (Idea would be: when merging both parameter tables and their lists of origins, if two parameters conflict you can check their origins and if both are from files, error).

Will focus on the currently failing tests, and adding new checks and tests for our agreed bad (but valid TOML) inputs.

c-prather · 2025-07-01T22:48:12Z

My only comment right now is to please add a cmake compile time option to use the old parser without any modifications. Downstream codes should be able to opt in to this breaking change.

Is there some specific break I can address? I've really tried to minimize any breakage for downstreams, and I don't anticipate anything major for my case. A flag to use the old parser completely unmodified would mean also storing the parameters the old way (all strings), which requires effectively keeping around the old versions of parameter_input.hpp/cpp and swapping them in at compile, as well as keeping both conventions in the two places Parthenon iterates blocks. Then you would need to compile with the old and new parsers for testing, as well...

So if there's any individual discrepancy I can fix, that's likely to be easier for me, benefits everyone, and provides less maintenance burden than two full codepaths.

Yurlungur

With the origin and multiple input files logic removed, I'm happy to endorse this. I'm still disappointed that TOML makes us do as much manually as it does, but this is still a big improvement as far as amount of code we have to maintain, IMO.

That said, I would like my suggested inline changes addressed. I also understand folks reticence since it is somewhat breaking. So would like to know all the downstreams are happy.

Yurlungur · 2025-07-03T15:43:20Z

    endif()
  endif()
 endif()
+include_directories("external/tomlplusplus")


Ok I tried messing with this a bit and it doesn't seem like TOML++'s build system supports this. So we should leave it for now and I'll submit an issue.

Yurlungur · 2025-07-03T15:47:29Z

+    paths.push_back(toml::path(prefix.append(key.str())));
+  }
+}
+std::vector<std::string> ParameterInput::GetAllPaths(toml::table &a) {


should there be a version of this that just returns all paths for the internal table?

Sure! This function was only written for your use writing origin and access tracking, so whatever calling convention you need is fine

adamdempsey90 · 2025-07-03T22:46:23Z

My only comment right now is to please add a cmake compile time option to use the old parser without any modifications. Downstream codes should be able to opt in to this breaking change.

Is there some specific break I can address? I've really tried to minimize any breakage for downstreams, and I don't anticipate anything major for my case. A flag to use the old parser completely unmodified would mean also storing the parameters the old way (all strings), which requires effectively keeping around the old versions of parameter_input.hpp/cpp and swapping them in at compile, as well as keeping both conventions in the two places Parthenon iterates blocks. Then you would need to compile with the old and new parsers for testing, as well...

So if there's any individual discrepancy I can fix, that's likely to be easier for me, benefits everyone, and provides less maintenance burden than two full codepaths.

After some time to digest parts of this, it looks like it's backwards compatible with the input file format (which was my main concern), so as long as this is tested thoroughly for bugs, I don't have any major hangups. It will take some effort to get artemis working with this, but I don't think it will be too bad.
Three questions:

This retains ordering of all parameters and blocks, correct?
Can you try to compile with c++20? The website says c++17, but it would be good to make verify it compiles with 20 for Kokkos 5.0. Because it's header only we can't just compile it separately.
Does this support parameters that are not contained in a block? For example, the first parameter in this:

# Input file
var = 2
<block1>
var = 3

that would be useful for my compiler.

c-prather · 2025-07-07T15:09:07Z

After some time to digest parts of this, it looks like it's backwards compatible with the input file format (which was my main concern), so as long as this is tested thoroughly for bugs, I don't have any major hangups. It will take some effort to get artemis working with this, but I don't think it will be too bad. Three questions:
* This retains ordering of all parameters and blocks, correct?

Ah, right. It can, but by default toml++ alphabetizes upon exporting things, so I'll have to keep an ordered list of keys explicitly. Will add that.

* Can you try to compile with c++20? The website says c++17, but it would be good to make verify it compiles with 20 for Kokkos 5.0. Because it's header only we can't just compile it separately.

Absolutely will give it a shot, yeah. The repo mentions it optionally uses some C++20 features if it's enabled, so I'm not worried here.

* Does this support parameters that are not contained in a block? For example, the first parameter in this:

# Input file
var = 2
<block1>
var = 3

that would be useful for my compiler.

It does! I'm adding an optional check to forbid them as a part of the table checker, but I plan to allow them in KHARMA too. I'm realizing I'll have to modify the Blocks() function to return only tables, not values, but that should be pretty simple.

…kref-boogaloo Add ParameterRef

…rings-2-blockref-boogaloo Revert "Add ParameterRef"

…pc-lab/parthenon into blb/toml

c-prather · 2025-07-09T17:15:37Z

I've rebased this on top of @Yurlungur's #1283, which in the process considerably simplified aspects of that PR, and I think I could cut it down the line count further while maintaining its functionality and supporting parameters outside blocks, new parameter types, etc. The TOML table was designed for the sort of things implemented over there (especially type management), so it integrates nicely.

The test failures are almost all due to my nesting calls to CheckAndUpdateQueries_, triggering its error conditions. Not sure how to fix all that, maybe @Yurlungur can take a look.

I really think this raises the question of whether we should just put any further parameter changes for a while atop this PR, which I swear makes things easier once you get used to it!

…kDesired test commented

Yurlungur · 2025-07-11T19:51:47Z

I have updated this branch to function on top of the docstrings branch, re-enabled provenance and CheckRequired and CheckDesired, and extended provenance, so that now the source is properly recorded and reported when checking orphans. All tests pass now except the output test, which is expected to break.

…o blb/toml

…d an inputs package.

Yurlungur · 2025-07-11T21:30:24Z

After discussion with @bprather I also added the functionality to stash raw inputs into the params of an Inputs package, meaning a developer can see the exact input deck and command line options that were set for a given run.

Detailed provenance information is available, and printed for things like warnings (for CheckOrphans for example) but is not otherwise printed or used. It could be though.

Yurlungur · 2025-07-11T21:48:44Z

Ah, right. It can, but by default toml++ alphabetizes upon exporting things, so I'll have to keep an ordered list of keys explicitly. Will add that.

@adamdempsey90 does the ordering need to persist across restarts? Presumably this would be desirable?

adamdempsey90 · 2025-07-12T18:18:30Z

Ah, right. It can, but by default toml++ alphabetizes upon exporting things, so I'll have to keep an ordered list of keys explicitly. Will add that.

@adamdempsey90 does the ordering need to persist across restarts? Presumably this would be desirable?

Probably not. The one place in artemis where this might matter stores things with a map instead of an ordered vector, so it should be fine with it being out of order. That being said, people might expect things to be in the input order always.

AstroBarker and others added 10 commits June 19, 2025 16:48

add tomlplusplus submodule

f9cdea6

Merge remote-tracking branch 'origin/jmm/next-output' into blb/toml

612dbbd

add queries record

a0563cc

Merge branch 'jmm/next-output' into jmm/docstrings

28d0dda

Replace parameters with TOML. Backward-compatible.

7c6b5b4

Change archive_parameters option to conform to real types

0db82f4

Merge branch 'jmm/next-output' of github:parthenon-hpc-lab/parthenon …

17a985e

…into blb/toml

Merge branch 'develop' into blb/toml

f6ad86c

Merge branch 'blb/toml' of github:parthenon-hpc-lab/parthenon into bl…

3d4dc5b

…b/toml

Add GetAllPaths to list out all leaf parameter paths, for iteration.

132f183

Yurlungur reviewed Jul 1, 2025

View reviewed changes

c-prather changed the base branch from develop to jmm/next-output July 1, 2025 20:32

Simplify, simplify parameters. No more origins table.

39089fb

Ben Prather and others added 4 commits July 1, 2025 17:16

Remove more parameter debugging outputs.

6dd8649

intermediate commit

15e6f87

Merge branch 'jmm/next-output' into jmm/docstrings

864f8e9

merge in next_output branch

a6c2dbf

Yurlungur reviewed Jul 3, 2025

View reviewed changes

jonahm-LANL added 2 commits July 3, 2025 12:02

Merge branch 'jmm/next-output' into jmm/docstrings

24b0719

almost there...

c1f2168

Base automatically changed from jmm/next-output to develop July 3, 2025 22:39

Merge branch 'develop' into jmm/docstrings

7e837bd

it works

19f380e

Yurlungur and others added 4 commits July 9, 2025 11:38

Merge pull request #1286 from parthenon-hpc-lab/jmm/docstrings-2-bloc…

2e7bed7

…kref-boogaloo Add ParameterRef

Revert "Add ParameterRef"

13cbae6

Merge pull request #1287 from parthenon-hpc-lab/revert-1286-jmm/docst…

7e775b8

…rings-2-blockref-boogaloo Revert "Add ParameterRef"

Merge (heavy airquotes) branch 'jmm/docstrings' of github:parthenon-h…

8e0a2e7

…pc-lab/parthenon into blb/toml

Yurlungur and others added 6 commits July 9, 2025 13:39

Merge branch 'develop' into jmm/docstrings

bb93a3c

add csv comment

b86fe1e

Merge branch 'develop' into jmm/docstrings-2-blockref-boogaloo

eea42fb

Merge branch 'jmm/docstrings-2-blockref-boogaloo' into jmm/docstrings

6c229da

ParamRef in a single commit

4bd0383

Pass (heavy airquotes) the tests. docstring error conditions and Chec…

c93ab26

…kDesired test commented

Base automatically changed from bprather/parametercuts to develop July 10, 2025 16:43

jonahm-LANL and others added 9 commits July 10, 2025 14:48

merge in latest changes from docstring MR

aff47d9

tests pass now

f5ebe91

comment out checkrequired and checkdesired

07c7809

Merge branch 'develop' into blb/toml

9d3c0da

tables build

5099ff1

don't need ostream overload

edc9ead

provenance works

c63f97a

oops hide the warning

b169872

Merge branch 'develop' into blb/toml

a7ac214

jonahm-LANL added 3 commits July 11, 2025 16:37

stash raw input strings...

eb0ddef

Merge branch 'blb/toml' of github.com:parthenon-hpc-lab/parthenon int…

73ee2ea

…o blb/toml

moved parameter input and argument parser into their own folder. Adde…

925d529

…d an inputs package.

remove unneeded toml table in parser

e125829

Yurlungur mentioned this pull request Jul 29, 2025

Provenance handling during package init and (mesh) defaults #1298

Closed

		for (auto pib : pin->Blocks("parthenon")) {
		std::string block_name = std::string(pib.first);

		inline void recursive_merge(toml::table &a, const toml::table &b, const toml::key &key,
		T &&el, bool check_dups) {

Uh oh!

Conversation

c-prather commented Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

PR Checklist

Uh oh!

Yurlungur left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

c-prather commented Jul 1, 2025

Uh oh!

Yurlungur commented Jul 1, 2025

Uh oh!

adamdempsey90 commented Jul 1, 2025

Uh oh!

c-prather commented Jul 1, 2025

Uh oh!

c-prather commented Jul 1, 2025

Uh oh!

Yurlungur left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamdempsey90 commented Jul 3, 2025

Uh oh!

c-prather commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

c-prather commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Yurlungur commented Jul 11, 2025

Uh oh!

Yurlungur commented Jul 11, 2025

Uh oh!

c-prather commented Jul 1, 2025 •

edited

Loading

c-prather commented Jul 7, 2025 •

edited

Loading

c-prather commented Jul 9, 2025 •

edited

Loading