Revive runregression system for automated regression testing by JunoRavin · Pull Request #961 · ammarhakim/gkeyll

JunoRavin · 2026-03-03T22:13:36Z

This PR serves as a baseline for the initial revival of the runregression Tool detailed in the design review here: #955

This tool was designed to permit a straightforward assessment of whether or not a given change or code modification modified the numerical output of a suite of simulations we have designed to stress test the whole simulation workflow. The basic idea:

The installed executable gkeyll has a command runregression so if you make install you automatically gain access to this system.
runregression can be configured (gkeyll runregression configure --source-dir /absolute/path/to/gkeyll/) to store the output accepted and individual checked results in a directory ~/gkylsoft/gkeyll-results/ where gkeyll-results/ would contain separate SQL databases for each layer (moments, vlasov, gyrokinetic, pkpm) and directories both accepted and the most recent runs of both Lua and C input files
runregression then takes a run command which will run the tests, though most commonly we will either do run create (to store the results in the accepted directories) or run check (to store the results in the runs directories and compare to the accepted results).

As part of this work a number of extensions over the previous regression system have been added with some assistance from Claude, especially for the SQL and Perl programming:

The vestigial Zero* ffi-driven wrapping of Gkeyll functionality has been deprecated in runregression.lua in favor of explicit Lua-C API wrapping in core/apps/zero_lw.c with functions registered such as the Lua side G0.Zero.arrayDiff pointing to array_diff_lw).
New functionality to compare dynvec and block_topo (block topology) output files.
GPU testing with an option GPU tolerance since GPU test cases are expected to have small differences with baseline CPU cases due to the non-deterministic nature of operations such as reductions (and there are only ever one set of accepted results, the CPU-generated results)
A timeout function which will default to a specialized Perl alarm system if the GNU timeout command is not found if users want to automatically time out of running long tests (or to further weed out tests that are being added for whether they are proper regression tests).

Many tests are currently in ignoretests.lua and I have not yet done anything in parallel (especially attempts to run multiple tests simultaneously and expedite testing in this way). But I want to get this looked over and reviewed now in preparation for the Open Source Software conference next week.

There is a major, if very small, change to C input files as part of this work: while .name is still something that can be passed to the input app struct, I now use the name of the executable to determine what the name of a regression test is by default to assist with file parsing when running C regression tests. That is why there are a large number of file changes in this PR.

…ned to support the new layering of the system to create databases per layer (moments, vlasov, gyrokinetic, and pkpm) as well as the fact that we support both Lua and C regression tests. As part of my attempt to further improve the system, the run command now takes a <layer> input (so run moments check as a valid command which would only check the moments layer). I also added new flags --lua-only, --c-only, and a --timeout flag which exists determine if a test should be ignored because it's not really a regression test (if something is added that exceeds the timeout, it gets added to the ignoretests.lua at that layer). Still a lot of work to do, but this seems to be working. Note that, while Lua input file checking behaves as it did in G2, the C input file regression tests copy the files in creg/ into their respective directories along with the Makefile from the install directory's share/ that allows us to build C input files linking against the installed shared libraries. To facilitate this testing **it is now required to pass the --source-dir when running configure as part of the runregression setup**

…e reviving the regression system somewhat non-trivial, chief among them how the C inputs files determined what the name of their output files are. To facilitate a more stable and easier to maintain regression system, all C input files now figure out what the name of the output files should be **from the name of the executable**. There were also various inconsistencies in a number of tests, such as how not every gyrokinetic C file was using the gyrokinetic_run_simulation API. I did my best to standardize everything across different layers, though some tests right now are just being skipped (such as various hyperdg kernel timers and a couple of moment multi-block tests).

… critical issue: gyrokinetic tests did not know where the data/ directory was and thus many gyrokinetic tests cannot create their accepted results. Since the configure now includes the source directory anyway because of how we're running C regression tests (by copying .c files into their respective gkeyll-results/layer/test_name folders and compiling the executable there with the Makefile in the gkylsoft/gkeyll/share directory that allows these executables to link against the installed shared libraries), we just add a layer_src field that allows us to see what is in the data/ directory of any given layer and read those files if they are needed by a test. Also some additional cleanup to only edit the ignoretests.lua file if we detect a test should be ignored (for example, because it is not taking a long time). That particular bit of functionality may need to undergo further iteration. I just structured things this way for now because I wanted to automate adding tests to ignoretests.lua at each layer. There are a number of tests at all levels in the ignoretests.lua now across both C and Lua. Some tests immediately segfault (like the wham_3x2v input file that is supposed to read 2x2v initial conditions). Some tests just don't work for various development reasons (like rt_escreen_sr no longer have moments specified correctly after all this time). Long to do list going through all these tests and finding what we want to keep. Also need to move a number of Vlasov regression tests to proper unit tests like the vlasov moment test. Need to make sure all regression tests actually create apps.

…rt, and ZeroUtil uses in runregression.lua and to instead move towards a system where the various array.c array_rio.c, and rect_cart_grid.c structs and functions are directly wrapped with our Lua-C API, similar to what we do for rect_decomp, so that these methods can be called directly in Lua in runregression.lua. CompareFiles still seems to work (regression tests still pass). Fun off-by-one errors as always as one works through converting between C and Lua. Also added a few more tests to moments ignoretests.lua. Not sure what adjustments will be needed to always be testing the neural network solvers in production but we can iterate on this front.

… dynvec_diff_lw function in zero_lw.c and registering that function so that it is callable in the same way that array_diff is used in the runregression tool. As a first pass, the dynvec_diff_lw checks the compatibility of comparing the two files (are there the same number of time outputs?) and then uses the dynvec_to_array function to convert the dynvec output and time grid to gkyl_arrays that can then utilize the same gkyl_array_diff infrastructure used for the array comparison. Seems to work out-of-the-box for a number of regression tests, though some have inconsistencies run-to-run in their integrated diagnostics. Likely the more robust thing is to use this function as-is but go through every input file, Lua and C, and not use GKYL_MAX_INT for the number of output integrated diagnostic computations, but instead switch to calculating the integrated diagnostics at set times.

…cks the config.mak to see if the system is configured to build on GPUs (CC=nvcc) just as an initial pass at decoding how the system has been built (since on the Lua side we don't have GKYL_HAVE_CUDA). A bunch of additions to the database such as whether the system is testing GPUs and various GPU specific information (pass/fail, timing, whether or not the GPU test differs in output from the CPU test). By default GPU testing runs both CPU and GPU tests and compares against a single CPU-created baseline (so create never utilizes GPUs) and the CPU and GPU runs are compared against each other to give more information about different failure modes. GPU comparisons force us to be a bit more careful about absolute vs. relative tolerances and now I have the system failing *only if* both absolute and relative differences are above set tolerances (allowing GPU runs to pass even when a number if near 0 or very large and one of the two comparisons will always fail). The GPU testing also takes a tolerance input, which may be necessary in general for a variety of tests (right now running with 1.0e-7 by default which allows for large number of Vlasov GPU tests to pass). More work to do, especially going through each regression test and determining why certain GPU tests fail on my workstation. But seems to be doing at least mostly what we want

…o try to do a quick sanity check that someone is not messing with things like resolution when comparing created vs. current runs, but this will always fail when we include the git hash as metadata (because if the git hash is slightly different, it might make the output files different by a single byte).

…o utilize runregression system.

…"gkeyll" in more places

…iles. Since these files just contain integers denoting connectivity of different blocks, we can do a simple comparison without worrying about floating point precision for each connection. Add this to the runregression script and remove the Euler multiblock test from ignorelists.lua

Maxwell-Rosen · 2026-03-04T14:50:19Z

I'm doing some testing on Perlmutter with a GPU build, and I have a few notes of feedback. I sent this to Jimmy on Slack and just wanted to make a formal GitHub comment.

In the documentation for the runregression, I find this line a little confusing. Configure: gkeyll runregression configure --source-dir /path/to/src. What does /path/to/src mean in this context? Does that mean the path to the gkeyll repo? If so, I think it should say that. I think this could be more specific in what the source means. Proposed amendment: Configure: gkeyll runregression configure --source-dir /path/to/gkeyll/repo.
Parallelism is in the works, but I asked about this.
I don't like that runregression.config.lua is written to the directory above where gkeyll is. Like, if my directory structure looks like $HOME/gkeyll and $HOME/gkylsoft, then this file goes straight to $HOME. I feel like it should either go inside gkylsoft, inside gkeyll and be added to the gitignore list (like config.mak), or inside the runregression-specific parts of gkylsoft. We should avoid cluttering $HOME and keep gkeyll contained inside its subfolders.
When running the create to make accepted results, I get the following output:

gkeyll runregression run create --timeout 120
GPU build detected (CC=nvcc in config.mak)
GPU build: GPU tolerance = 1e-07
Running regression tests ...


[Lua] Running moments/luareg/rt_euler_mixture_shock_bubble.lua ...

I find this output confusing for several issues. For one, this printout makes it seem like the regression tests are run on GPU. In reality, these tests are being run on CPU. Furthermore, why is the GPU tolerance printed when nothing is being compared? Comparison should only happen in the check command, not create. Proposed ammended print out:

gkeyll runregression run create --timeout 120
GPU build detected
Creating accepted regression results on CPU
Running regression tests ...


[Lua] Running moments/luareg/rt_euler_mixture_shock_bubble.lua ...

I take issue with the naming of these commands. For instance, gkeyll runregression run create repeats the word "run" twice. We can clarify the syntax in a few ways. We could remove the run command, as this is implied from the runregression command, collapsing commands to look like

gkeyll runregression create --timeout 120
gkeyll runregression check --timeout 120
gkeyll runregression moments check

I dislike that the runregression has a submethod run, which further has submethods, so if you were to --help, you would need to traverse many layers of commands. Instead, putting all commands at the runregression --help layer would be much clearer.
Or, if we want to keep this tree of dependencies, then renaming runregression run to regression run would read much cleaner.

…ltiple tests simultaneously with their systems available CPU cores (so no parallelism within a test, but parallelism across tests). The structure here is that instead of the previous runLuaTest and runCTest structure, we now separate the system into a prepareLuaRun and prepareCRun, followed by an executeBatch function that uses shell background jobs to launch multiple simulations at once, before executing a blocking wait call for all jobs to finish and the single parent process to then handle the writing of data to the SQL database. This use of shell scripting generated by the Lua tool was already being utilized for the C regression tests to perform the sequence of tasks for copying the .c input files from their appropriate <layer>/creg directories, copying the Makefile from the installed gkylsoft/gkeyll/share/ directory, and compiling and running linked to the shared libraries (with various command line options like utilizing GPUs with -g) so we've just extended what the Lua tool does in terms of shell scripting. The choice to do this is because LuaJIT has no OS threads. Note that in this structure each test in parallel writes its own output text file in its run directory, and those files are what are then processed when all tests have been run (so that we can write to the SQL database serially). A few other notes about issues caught thus far in this work: 1. I am still discovering occasional issues where the C-side crashes, such as the case where apparently one of the regression tests was producing a dynvec of size 0 (like it only initializes data and does not take time steps). I have tried adding guards to size 0 output to just trivially pass and then test other things written out by that test, but more work is needed whether in general such a test *should* exist or if any test constructed this way is more suited for a specialized unit test. 2. Before we were walking through the run directories in the comparison stage, but I have now elected to switch to walking through the accepted directories in the comparison stage. My logic is that the accepted results are the ground truth; if the run directory has fewer or more files than the accepted results, that test should *automatically* fail because it's obviously not running what we consider the accepted output (either because the test changed or worse, the simulation itself crashes and doesn't even each the final output frame).

… comparisons, likely because of integration of certain geometric quantities (since we have not yet separated the spacetime from the state variables) is producing garbage that itself is non-deterministic what the exact value of garbage is.

manauref · 2026-03-05T16:56:52Z

Responding to some of @Maxwell-Rosen points above.

I think it should be possible to remove --source-dir altogether, and have the system automatically detect where the source directory is based on other files. For example, for C reg tests it uses the Makefile in gkylsoft/gkeyll/share/. That Makefile has a line like -include <source-dir>/gkylsoft/gkeyll/share/config.mak. So one could parse the Makefile, and retrieve <source-dir>.
@JunoRavin what if we rename runregression to gkeyll_ci or something like it? because aside from Max's run comment, this system can also do unit tests (right?), not just regression tests. And it'll be our core CI script.

Following up on some things discussed with @JunoRavin privately, but I think he's onto these already:

I had some issues with testing from a build that is somewhere other than $HOME/.
I think the system should not require absolute paths. That will make it onerous for people to use the system, and we need to make this extremely easy to use.
Lines in -h menus could be formatted better. Maybe just impose a maximum number of characters per line.

My most important request: that we look into getting this running nightly and reporting the results to Github. Our sundials collaborators have this system running from a machine at Livermore I think, so we should just talk to them and see if we can copy what they did.

Maxwell-Rosen · 2026-03-05T17:56:11Z

@manauref, I'm not sure the name gkeyll_ci is ideal, since commands would look like gkeyll gkeyll_ci, which is repetitive. I'd suggest a name like test or ci. These are concise and not repetitive. I would suggest test, as ci is an abbreviation for something that only software people really understand. So syntax would look like

gkeyll test configure
gkeyll test regression create
gkeyll test regression moments check
gkeyll test unit create
gkeyll test unit gyrokinetic check

… improvements with respect to the prefix and run-only flags.

1. Try to add some more line breaks and formatting of comments. Right now I'm trying to make the comments relatively compact with line breaks at sentences where needed. When my terminal is my whole screen there are no awkward line breaks now, but there are still line breaks on a compact small terminal. 2. Finds the prefix from config.mak to try to reduce the headache of setting the prefix consistently 3. Allow for the use of just a test name with the --run-only command

manauref · 2026-03-05T22:34:39Z

I've tried it some more after recent commits, I'm increasingly (very) happy with this. I have one small request:
1: Can you add a verbose option to run check? so that it tells us which file failed the comparison, and possibly how or by how much. This used to be useful for identifying where to start looking when something broke. Edit: I now see that this is possible

gkeyll runregression -v run check -r rt_gk_sheath_2x2v_p1

which provides this

It might be worth giving run check it's own -v option instead, and parsing the info in this screenshot so it only prints out the failed files (and without the paths because they are distracting).

and I have one big request:
2: That we run this daily and plug this into GH as we've discussed offline.

happy to help however I can with 2.

… prefix and just show <layer>/accepted (or runs)/test_name/file_name. Also add a failedFiles table that is written to a text file and is printed to the screen via log() (it is not just printed with verbose option, since I assume if a test fails like this, users will want to know files that are failing immediately).

1. runregression.config.lua is not stored in gkeyll-results/ and we parse the config.mak for the prefix so that we can find this configuration file whenever we run (instead of always being loaded from its storage in the home directory). 2. Update comments for the fact that the source-dir is an absolute path to the gkeyll repo (I cannot find any other place we set the source directory. Every other environment variable path we set are various flavors of prefixes and install locations, not the location of the actual repository). 3. Updating GPU comments to note that create occurs on CPUs and to only provide the GPU tolerance screen message under certain conditions (check, and check without --no-gpu).

JunoRavin · 2026-03-06T02:50:46Z

In the documentation for the runregression, I find this line a little confusing. Configure: gkeyll runregression configure --source-dir /path/to/src. What does /path/to/src mean in this context? Does that mean the path to the gkeyll repo? If so, I think it should say that. I think this could be more specific in what the source means. Proposed amendment: Configure: gkeyll runregression configure --source-dir /path/to/gkeyll/repo.

I have attempted to clarify that this is an absolute path to gkeyll

Parallelism is in the works, but I asked about this.

This is done now utilizing the --jobs flag to the run command (so run check --jobs 4 would run tests 4 at a time)

I don't like that runregression.config.lua is written to the directory above where gkeyll is. Like, if my directory structure looks like $HOME/gkeyll and $HOME/gkylsoft, then this file goes straight to $HOME. I feel like it should either go inside gkylsoft, inside gkeyll and be added to the gitignore list (like config.mak), or inside the runregression-specific parts of gkylsoft. We should avoid cluttering $HOME and keep gkeyll contained inside its subfolders.

Done. It's stored in gkylsoft/gkeyll-results/ now

When running the create to make accepted results, I get the following output:
gkeyll runregression run create --timeout 120
GPU build detected (CC=nvcc in config.mak)
GPU build: GPU tolerance = 1e-07
Running regression tests ...


[Lua] Running moments/luareg/rt_euler_mixture_shock_bubble.lua ...
I find this output confusing for several issues. For one, this printout makes it seem like the regression tests are run on GPU. In reality, these tests are being run on CPU. Furthermore, why is the GPU tolerance printed when nothing is being compared? Comparison should only happen in the check command, not create. Proposed ammended print out:
gkeyll runregression run create --timeout 120
GPU build detected
Creating accepted regression results on CPU
Running regression tests ...


[Lua] Running moments/luareg/rt_euler_mixture_shock_bubble.lua ...

Done.

I take issue with the naming of these commands. For instance, gkeyll runregression run create repeats the word "run" twice. We can clarify the syntax in a few ways. We could remove the run command, as this is implied from the runregression command, collapsing commands to look like
gkeyll runregression create --timeout 120
gkeyll runregression check --timeout 120
gkeyll runregression moments check
I dislike that the runregression has a submethod run, which further has submethods, so if you were to --help, you would need to traverse many layers of commands. Instead, putting all commands at the runregression --help layer would be much clearer. Or, if we want to keep this tree of dependencies, then renaming runregression run to regression run would read much cleaner.

I'm not changing names or command chains like this right now. I personally am not a fan of any of the suggested changes.

JunoRavin · 2026-03-06T02:56:34Z

I think it should be possible to remove --source-dir altogether, and have the system automatically detect where the source directory is based on other files. For example, for C reg tests it uses the Makefile in gkylsoft/gkeyll/share/. That Makefile has a line like -include <source-dir>/gkylsoft/gkeyll/share/config.mak. So one could parse the Makefile, and retrieve <source-dir>.

I can't figure out a way to automate the location of source-dir. We don't store the location of where the repository is anywhere as far as I can tell. We have environment variables for the install location so I was able to automate the prefix location, but if there is a way to automate where the gkeyll repo is located, I can't figure out what it is.

@JunoRavin what if we rename runregression to gkeyll_ci or something like it? because aside from Max's run comment, this system can also do unit tests (right?), not just regression tests. And it'll be our core CI script.

I don't want to change the names right now. I've been typing runregression run check enough that this is very comfortable for me and I feel like I can do this type of demonstration live for the OSSFE talk.

Following up on some things discussed with @JunoRavin privately, but I think he's onto these already:

I had some issues with testing from a build that is somewhere other than $HOME/.

I think the system should not require absolute paths. That will make it onerous for people to use the system, and we need to make this extremely easy to use.

Lines in -h menus could be formatted better. Maybe just impose a maximum number of characters per line.

I think I have addressed these issues with the option to just run test names and I've tried to improve the comment formatting, though it may still need refinement.

My most important request: that we look into getting this running nightly and reporting the results to Github. Our sundials collaborators have this system running from a machine at Livermore I think, so we should just talk to them and see if we can copy what they did.

On the agenda!

1: Can you add a verbose option to run check? so that it tells us which file failed the comparison, and possibly how or by how much. This used to be useful for identifying where to start looking when something broke. Edit: I now see that this is possible

I think I have addressed this with the new writing of which files are failing to a Lua table (failedFiles) that is then written to a text file per run directory and also written to screen with log(). Let me know if there is more you want on this front. I also pruned the full path names which I think helps with the formatting.

JunoRavin · 2026-03-06T13:46:44Z

Based on a question from @Maxwell-Rosen I want to clarify how the parallel regression system works when running on GPUs. All GPU testing is serial. This limitation is because I am currently just leveraging system calls and letting the OS scheduler handle which tests go with which core through shell scripts the Lua tool writes (mixing & with a final wait call to block the completion of the batch of tests). Since I'm just using system calls, I don't (let's say yet) know how to tell the system "this test runs on GPU 0 and this test runs on GPU 1" efficiently, whereas leveraging OS calls means I never have to say "core 0 runs test A, core 1 runs test B, etc."

So if you run the system on GPUs to check results, the following flow should occur if you use --jobs 4 with run check:

[Batch-Lua] Launch 4 CPU tests simultaneously (&/wait)
-> collect test 1: postRun (check) -> runGpuVariant (serial) -> DB write
-> collect test 2: postRun (check) -> runGpuVariant (serial) -> DB write
-> collect test 3: postRun (check) -> runGpuVariant (serial) -> DB write
-> collect test 4: postRun (check) -> runGpuVariant (serial) -> DB write
[Batch-Lua] Launch next 4 CPU tests ...
...
[Batch-C] Launch 4 CPU C tests simultaneously (&/wait)
-> collect test 1: postRun (check) -> runGpuVariant (serial) -> DB write
...

All collect calls are serial and sequential and paired with the runGpuVariant() function call for determining if we are also running the test on GPUs.

…as I iterated with Claude on a few of the specific details of the refactor

manauref · 2026-03-07T21:05:04Z

Some more feedback after more use:

gkeyll runregression configure -h shows several options. These are not organized alphabetically, not in order of need. It makes it look like they are all either optional (are they?) or needed. But my understanding is that --source-dir is the only one always needed. So maybe that should be at the top. If they are all optional then it's ok as it is now.
Right now luareg/ignoretests.lua also lists the ignored C tests. I think this isn't right. I think there should be a separate creg/ignoretests file to list the ignored C tests.
Is there a way to force create or check a test that is in the ignored tests list?
Running check on a test that fails produces
[C] Compiling gyrokinetic/creg/rt_gk_sheath_2x2v_p1 ...

... completed in 6 sec
... gyrokinetic/creg/rt_gk_sheath_2x2v_p1 FAILED!
  Failing files (111):
    rt_gk_sheath_2x2v_p1-elc_source_M2par_0.gkyl  [DIFF]
    ...

followed by a long list of failing files.
4.1) What does [DIFF] mean? could it be explained in the print out. Are there other possible outcomes other than [DIFF]?
4.2) Sometimes one wants to find out by how much the comparison failed. It helps to know whether these are O(1) changes or O(1e-9) changes. Could check have a -v option that prints more info, specifically what the largest error comparison that made it fail for each file is?

…ssion system: 1. configure now requires --source-dir and tells user they must provide --source-dir (and it is the first flag described when doing configure -h) 2. I have separated ignoretests.lua into ignore_lua_tests.lua (in <layer>/luareg) and ignore_c_tests.lua (in <layer>/creg) and process these two ignore lists separately. I have also done the same thing for the moat.lua (separating into moat_lua.lua and moat_c.lua) and put a few tests at each layer in the mother-of-all-tests lua file so that this functionality is working. 3. I moved the description of --all flag to be a run flag, not a runregression flag, and have tested this overrides what is in ignore_lua_tests.lua and ignore_c_tests.lua. You can combined this flag with --c-only and --lua-only to override only what is the corresponding the ignore list. 4. I have added more information to the diff/missing and other flagged failure commands and have now further added the option to queryrdb to get specific information about a specific test similar to the --run-only flag gkeyll queryrdb --layer gyrokinetic query --id 1 --test rt_gk_sheath_2x2v_p1 which gets the most recent run and the information on the gk_sheath_2x2v_p1 test. You can also still pass a test ID (a number) if you choose but since you may not know which number corresponds to which test, hopefully this helps navigate the database.

manauref · 2026-03-09T17:53:01Z

  };

+  // Set app output name from the executable name (argv[0]).
+  snprintf(app_inp.name, sizeof(app_inp.name), "%s", app_args.app_name);


why is changing the way sim name is specified necessary?

It automates the way the runregression system determines what the name of the test is, instead of causing potential downstream errors if the .name is inconsistent with what the regression system expects (originally these C regression tests did not uniformly have the rt_* prefix and this was making the regression system checking C tests a pain). I documented this in the PR that this was a significant boon to parsing test names and eliminated inconsistencies between Lua and C test names when the tests were actually identical (since Lua gets the name of the output files just from the name of the script, whereas C input files were manually specifying this).

This only affects the C regression tests. .name is still a perfectly acceptable input for any C production test.

oh there is something I don't like there actually, I cannot simply copy paste the regression test, compile it with gkylsoft/gkeyll/share/Makefile and run it using simply ./ command...

It seg faults now because there are no default app name anymore. I think would be good to conserve that feature so that we can manually compile and run with ./ any regression test.

You can do this. That is literally what the runregression system is doing. I am not understanding what you are doing that this does not work?

ahoffman@ahoffman-lt gkeyll % mkdir ctest_tcv_2x2v.o ahoffman@ahoffman-lt gkeyll % cd ctest_tcv_2x2v.o ahoffman@ahoffman-lt ctest_tcv_2x2v.o % cp ../gyrokinetic/creg/rt_gk_tcv_iwl_adapt_source_2x2v_p1.c . ahoffman@ahoffman-lt ctest_tcv_2x2v.o % cp ../../gkylsoft/gkeyll/share/Makefile . ahoffman@ahoffman-lt ctest_tcv_2x2v.o % make cc -O3 -g -ffast-math -I. -DGKYL_USING_FRAMEWORK_ACCELERATE -DGKYL_SHARE_DIR="/gkeyll/share" -DGKYL_HAVE_LUA -I/Users/ahoffman/gkylsoft/gkeyll/include -Icore -I/Users/ahoffman/gkylsoft/superlu/include/ -Izero -I/Users/ahoffman/gkylsoft/luajit/include/luajit-2.1/ -Izero -Izero rt_gk_tcv_iwl_adapt_source_2x2v_p1.c -o rt_gk_tcv_iwl_adapt_source_2x2v_p1 -L/Users/ahoffman/gkylsoft/gkeyll/lib -Wl,-rpath,/Users/ahoffman/gkylsoft/gkeyll/lib -lg0pkpm -lm -lpthread -L. -L/Users/ahoffman/gkylsoft/superlu/lib/ -L. -L/Users/ahoffman/gkylsoft/luajit/lib/ -L. -L. -framework Accelerate -lsuperlu -Wl,-rpath,/Users/ahoffman/gkylsoft/luajit/lib/ -lluajit-5.1 -lm -lpthread -ldl ld: warning: ignoring duplicate libraries: '-lm', '-lpthread' ahoffman@ahoffman-lt ctest_tcv_2x2v.o % ./rt_gk_tcv_iwl_adapt_source_2x2v_p1 zsh: segmentation fault ./rt_gk_tcv_iwl_adapt_source_2x2v_p1

ok I tried with the 3x2v and it worked. Something else went wrong

ammarhakim

This is ready to merge. We can take a look at other changes later.

Given Jimmy's tutorial on Tuesday in Germany, I am dismissing this review for now. We can discuss more in a new branch, if needed.

Maxwell-Rosen · 2026-03-12T20:38:13Z

-  gkyl_gyrokinetic_app_cout(app, stdout, "Number of RK stage-3 failures %ld\n", stat.nstage_3_fail);
-  gkyl_gyrokinetic_app_cout(app, stdout, "Number of write calls %ld\n", stat.n_io);
-  gkyl_gyrokinetic_app_print_timings(app, stdout);
+  gkyl_gyrokinetic_run_simulation(&run_inp);


This is really really wrong and these changes should not be made. There is no run method for the POA scheme

good catch Max. Please submit a PR fixing.

JunoRavin added 12 commits February 22, 2026 22:18

Merge branch 'main' into revive-runregression

019c6e0

Merge branch 'main' into revive-runregression

1ba5c8e

Adding some additional comments/clarifying current comments for how t…

b35c49c

…o utilize runregression system.

Fixing name of code in main comment now that we are officially using …

3a52f8f

…"gkeyll" in more places

JunoRavin requested review from Antoinehoff, JonathanGorard, Maxwell-Rosen, VigneshKrsnaKumar, akashukla, ammarhakim, dingyunl, jjz73, jmrodman, johnson452, kltrbrds, manauref, nikolabukowiecka and tnbernard March 3, 2026 22:15

JunoRavin added 2 commits March 5, 2026 10:19

JunoRavin added 2 commits March 5, 2026 15:13

One final GR addition for now. Need to get to work on quality of life…

4f572d3

… improvements with respect to the prefix and run-only flags.

JunoRavin added 2 commits March 5, 2026 21:17

Updating some comments, especially removing thought process comments …

051898a

…as I iterated with Claude on a few of the specific details of the refactor

manauref previously requested changes Mar 9, 2026

View reviewed changes

Antoinehoff approved these changes Mar 9, 2026

View reviewed changes

JonathanGorard approved these changes Mar 9, 2026

View reviewed changes

ammarhakim approved these changes Mar 10, 2026

View reviewed changes

ammarhakim merged commit 8d1a4d8 into main Mar 10, 2026
1 check failed

Maxwell-Rosen reviewed Mar 12, 2026

View reviewed changes

Conversation

JunoRavin commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Maxwell-Rosen commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

manauref commented Mar 5, 2026

Uh oh!

Maxwell-Rosen commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

manauref commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JunoRavin commented Mar 6, 2026

Uh oh!

JunoRavin commented Mar 6, 2026

Uh oh!

JunoRavin commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

manauref commented Mar 7, 2026

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!

ammarhakim left a comment

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

JunoRavin commented Mar 3, 2026 •

edited

Loading

Maxwell-Rosen commented Mar 4, 2026 •

edited

Loading

Maxwell-Rosen commented Mar 5, 2026 •

edited

Loading

manauref commented Mar 5, 2026 •

edited

Loading

JunoRavin commented Mar 6, 2026 •

edited

Loading