What is the workflow for fixing a model?

[nrnhines]

I'm working on windows with the latest msys (gcc 12.1.0) and the nrn olupton/more-cxx . There are 32 models that fail with

runmodels --norun --workdir foo

and I think most of those merely require some minor tweaking of mod files. E.g.

    "7399": {
...
           "AMPA.cpp:460:25: error: cast from 'void*' to 'long unsigned int' loses precision [-fpermissive]",
            "  460 |         lpst = (double)((unsigned long)hoc_Ecalloc(msn,(sizeof(SynS))));",
            "      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~",

At present, cache/7399.zip was unzipped by runmodels into foo/lytton98
I can easily clone the related github repository and work on that manually, but is there a way to retest with something like

runmodels --norun --workdir foo 7399

[alexsavulescu]

Currently there is no way to retest with runmodels (#29)

What I do is I go to the .json report file and have a look at the model run_info information to see where the model was run (model_dir) and from the nrn_run what was the command that was issued (RUNNING - > ):

"3682": {
....
 "nrn_run": [
            "RUNNING -> ./x86_64/special -nobanner %model_dir%/mosinit.hoc %model_dir%/driver.hoc",
            "\t0 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "\t1 ",
            "Spike at 40.5 ",
            "Spike at 81.15 ",
            "Spike at 108 ",
            "Spike at 133.65 ",
            "Spike at 180.775 ",
            "Spike at 201.3 ",
            "Total spikes: 6 ",
            "\t1 ",
            "\t1 ",
            ""
        ],
"run_info": {
            "driver": "/Users/savulesc/Workspace/nrn-modeldb-ci/test3682/synmap/driver.hoc",
            "init": "/Users/savulesc/Workspace/nrn-modeldb-ci/test3682/synmap/mosinit.hoc",
            "model_dir": "/Users/savulesc/Workspace/nrn-modeldb-ci/test3682/synmap",
            "script": [
                "echo 'use_mcell_ran4(1)' > temp",
                "cat mosinit.hoc >> temp",
                "mv temp  mosinit.hoc"
            ],
            "start_dir": "/Users/savulesc/Workspace/nrn-modeldb-ci/test3682/synmap"
        },

[alexsavulescu]

and work in the model_dir directly

[nrnhines]

I was wondering why g++-12 was more strict in the windows environment that in linux. I guess it may have something to do with
the old scripts called by nrnivmodl in windows that end up with compile lines like

x86_64-w64-mingw32-g++.exe -DDLL_EXPORT -DPIC -I/cygdrive/c/nrn/include -I/cygdrive/c/nrn/src/scopmath -I/cygdrive/c/nrn/src/nrnoc -I/cygdrive/c/nrn/src/oc  -c AMPA.cpp

vs the linux nrnivmodl compile liine

/usr/bin/g++-12 -g  -O0 -fstack-protector -Wno-write-strings  -std=c++14 -DMPI_NO_CPPBIND=1 -DOMPI_SKIP_MPICXX=1 -DMPICH_SKIP_MPICXX=1 -DHAVE_CONFIG_H  -I".." -I.   -I/home/hines/neuron/nmodlcxx/build/install/include  -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -fPIC -c AMPA.cpp -o AMPA.o

Especially since an msys compile line during build of nrniv is much more similar to linux and looks like:

[5/10] C:\msys64\mingw64\bin\c++.exe -DHAVE_CONFIG_H -DMPICH_SKIP_MPICXX=1 -DMPI_NO_CPPBIND=1 -DOMPI_SKIP_MPICXX=1 -Dnrniv_lib_EXPORTS -DHOC=1 -DINTERVIEWS=1 -DOOP=1 -IE:/hines/neuron/nmodlcxx/src/ivoc -IE:/hines/neuron/nmodlcxx/src/nrncvode -IE:/hines/neuron/nmodlcxx/src/nrniv -IE:/hines/neuron/nmodlcxx/src/nrnoc -IE:/hines/neuron/nmodlcxx/src/oc -IE:/hines/neuron/nmodlcxx/build -IE:/hines/neuron/nmodlcxx/build/src/nrncvode -IE:/hines/neuron/nmodlcxx/build/src/nrnjava -IE:/hines/neuron/nmodlcxx/build/src/nrnoc -IE:/hines/neuron/nmodlcxx/build/src/nrnpython -IE:/hines/neuron/nmodlcxx/build/src/oc -IE:/hines/neuron/nmodlcxx/build/src/parallel -IE:/hines/neuron/nmodlcxx/build/src/sundials -IE:/hines/neuron/nmodlcxx/build/src/sundials/shared -IE:/hines/neuron/nmodlcxx/external/Random123/include -IE:/hines/neuron/nmodlcxx/src -IE:/hines/neuron/nmodlcxx/src/gnu -IE:/hines/neuron/nmodlcxx/src/mesch -IE:/hines/neuron/nmodlcxx/src/nrnmpi -IE:/hines/neuron/nmodlcxx/src/nrnpython -IE:/hines/neuron/nmodlcxx/src/parallel -IE:/hines/neuron/nmodlcxx/src/scopmath -IE:/hines/neuron/nmodlcxx/src/sparse -IE:/hines/neuron/nmodlcxx/src/sparse13 -IE:/hines/neuron/nmodlcxx/src/sundials -IE:/hines/neuron/nmodlcxx/src/sundials/cvodes -IE:/hines/neuron/nmodlcxx/src/sundials/ida -IE:/hines/neuron/nmodlcxx/src/sundials/shared -IE:/Python39/Include -IE:/hines/neuron/nmodlcxx/build/src/nrniv/oc_generated -isystem E:/hines/neuron/nmodlcxx/external/iv/src/include -g  -O2 -Wno-write-strings -std=c++14 -MD -MT src/nrniv/CMakeFiles/nrniv_lib.dir/__/oc/hoc.cpp.obj -MF src\nrniv\CMakeFiles\nrniv_lib.dir\__\oc\hoc.cpp.obj.d -o src/nrniv/CMakeFiles/nrniv_lib.dir/__/oc/hoc.cpp.obj -c E:/hines/neuron/nmodlcxx/src/oc/hoc.cpp

I think I'll spend some time seeing if the linux nrnivmodl can replace the legacy mingw nrnivmodl.