Draft: Modernise OP routines

[warrickball]

The OP routines (kap/private/op_*.f) have long been suspected of bit-for-bit inconsistency, which occasionally but inconsistently manifests in the radiative_levitation test (e.g. in 72c52f2 and 54c4dc0. This PR is a medium-term project to modernise the largely F77-style source to remove these doubts and possibly even fix some bugs along the way.

The first few files were quite straightforward but there's then a tangled mess of calls across various files, which means most of the rest probably have to be modernised in one pass. I tried this and got stuck, so started over, just tweaking what I could.

Some goto statements will require some careful restructuring to use modern flow control (cycle, exit, etc).

This also doesn't all have to be done in one PR. If there are substantial stumbling blocks, we can raise issues for those and merge everything else we manage to modernise.

[fxt44]

ok. this project will need lots of testing, verification, etc. it might be useful to have both old and new version so that direct comparisons can be done on the fly.

[evbauer]

Thanks for taking this on. Just pushed an update to do1_test_source so that it will test the relevant cases for bit-for-bit issues.

[evbauer]

I ended up having to tweak 1.4_ms_op_mono so that the photo restart would give something meaningful. It was giving a superficial failure at first because it was set to max_model_number = 10, and also restarting from photo 10. So on restart it would take an extra step and then stop at step 11, and obviously therefore be in a different state than before. Now that's fixed, so the photo checksum failure being reported is legitimate. This test case is using the 'mombarg' OP option, so this might point to a bit-for-bit issue somewhere in there.

Interestingly, radiative_levitation is passing on Cannon right now even when checking the photo restart checksum, so I guess its failures are more intermittent. It might be good to get another machine or two testing the latest commit on this branch so we can see if we get consistent checksums across machines.

[fxt44]

It might be good to get another machine or two testing the latest commit ...

i'm on it, as soon as the current test suite runs finish later today i'll fire again.

[warrickball]

Do we run unit tests on the OP routines? It looks to me like the answer is "no" I guess because they aren't installed by default. I can try turning them on at least on this branch.

I'm running the latest commit on bluebear_ifort too.

[fxt44]

https://docs.mesastar.org/en/release-r22.11.1/test_suite/1.4M_ms_op_mono.html#m-ms-op-mono

it can be a stub. i run with

setenv MESA_OP_MONO_DATA_PATH /Users/fxt/mesa_work/OP4STARS_1.3/mono
setenv MESA_OP_MONO_DATA_CACHE_FILENAME /Users/fxt/mesa_work/OP4STARS_1.3/mono/op_mono_cache.bin
setenv MESA_OP_MONO_MASTER_GRID /Users/fxt/mesa_work/OP_mono_master_grid_MESA_emesh.txt

which should activate the basic functionality being tested.

[fxt44]

having to delete and rebuild op_mono_cache.bin every N versions used to be an issue. not sure if it still is. i'll rebuild it as an additional test.

[warrickball]

By "unit tests" I mean the tests that are run when the module is built, not the runs in the test suite (which I think of as integration tests). See e.g.

mesa/kap/test/src/test_kap_support.f90

Lines 54 to 64 in 04e4de4

	call test1(quietly, 1, 'fixed metals', ierr)
	if (ierr /= 0) call mesa_error(__FILE__,__LINE__)
	call test1(quietly, 2, 'C/O enhanced', ierr)
	if (ierr /= 0) call mesa_error(__FILE__,__LINE__)
	!call test1(quietly, 3, 'op_mono', ierr)
	!if (ierr /= 0) call mesa_error(__FILE__,__LINE__)
	call test1(quietly, 4, 'AESOPUS', ierr)
	if (ierr /= 0) call mesa_error(__FILE__,__LINE__)

where the op_mono test appears to be commented out.

[fxt44]

yes, i understand what a unit test is. just reminding what tests we do have.