-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command Line Options Cleanup, main branch (2024.03.05.) #525
Command Line Options Cleanup, main branch (2024.03.05.) #525
Conversation
In general I agree with all points so will hit approval once it passes the CI |
6c87150
to
2bb95b8
Compare
Note that I also removed all of the "required options" as well. 🤔 Providing default values for absolutely all of the options. Because I've always found it pretty painful that none of our executables can just be run as-is. 😦 Well, now they can. At least most of them... (Since for some of the options it's not easy to find universal defaults... 😦) So, something like this:
|
2bb95b8
to
cd636d8
Compare
It's ready now, after having updated the Alpaka and Kokkos executables as well. 😉 |
Made all structs behave the same way, and introduced print operators for all of them.
Made all of the applications print their configuration parameters in a uniform way, using the helper code introduced with the "options code".
cd636d8
to
93dc0d1
Compare
This all started out from a report on Mattermost that the throughput measuring executables are not working at the moment. But instead of merely fixing a typo in the "options code", I decided that it was time to do a thorough cleanup of it.
I did a number of things:
float
ordouble
precision when specifying runtime parameters on the command line. So these options are always just specified asfloat
-s, and then those configuration parameters may be used indouble
precision calculations later on.boost::program_options
write the configured parameters into C++ variables "directly". Instead of declaring the option first, and then extracting the option ourselves later on.read(...)
functions, since in a few cases we still need to do some non-trivial operations while interpreting the user-provided arguments. Though much of the code from theseread(...)
functions could be removed.This whole cleanup, I believe, was in the end very useful. Since I now have a new idea for why track finding in #509 would not be working. 🤔