lanl / ram-scb Goto Github PK

The current docs only list:

• IESC : for use in SWMF
• VOLS : Volland-Stern
• WESC : Weimer (where the reference is given in PARAM.xml as both 2000 and 2001)

Options W5SC (Weimer 2005) and RSCE (self-consistent E) do not appear to be documented anywhere.

This can probably be addressed in #75

Two issues here:

1. As noted in #78 the share library is out of date. One of the changes removes setting an octal mask which is now prohibited under GCC10. This can be solved in the short term by adding the -fallow-invalid-boz flag, but this flag (if added) should be removed when the share library is updated.
2. Interfaces in our dependencies now trigger a strict check for argument mismatches, leading compilation to fail. Under GCC10 these can be converted to warnings by adding a new flag: -fallow-argument-mismatch.

The IRI requires the igrf*.dat and dgrf*.dat files to work correctly. These are in the input directory but are not copied over to the run directory when make rundir is called.

(See also #92 as the IRI we include is, I think, fairly out of date)

We need the LACC number in the README.md

The new CI replaces our old, defunct Travis CI.
Two things still need to happen:

1. The CI badge in README.md needs to be updated to point to the GitHub actions outcome.
2. The .travis.yml file needs to be removed and any Travis integration turned off.

SCE adds new dependencies (GLOW) as well as duplicating current dependencies (IRI).
Ideally the SCE dependencies should all be in srcExternal and we should have no duplication. The IRI for GLOW/SCE also has its own input files that are duplicates of the IRI input files in the main input folder. This may require some work to streamline the build and ensure that all input files are moved into run directories correctly.

See also #92 and #93.

While we can't necessarily control some of our dependencies, there are still a couple of GOTO statements in the codebase (ModRamFunctions.f90). These are coupled with DO [line number] ... CONTINUE loop control, and can be rewritten to conform to modern Fortran standards.

These are an ideal case for some unit tests. So first we can write unit tests for functions with old-style control flow (and make sure that the tests are thorough and pass), then update the functions to use modern approaches.

The bundled share library is out of date and incompatible with GCC10.
In particular, the make_dir subroutine in share/Library/src/ModUtility.f90 sets an octal permission mask. This is no longer allowed under GCC10, but the routine has already been rewritten in the upstream repo (and actually has a different calling syntax).

The share folder should be updated to the latest version from SWMF.

Presently the Travis CI seems to only run one test (test 3?)
All tests should actually work, and so all should be run when pull requests are sent.

Currently installing as part of the SWMF requires making a number of changes manually that should be automated, or otherwise handled:

• Commenting out PLE_OBJECTS in ModRamRun.f90
• Commenting out the DoUsePlane_SCB IF block in src/Makefile
• Removing the share directory
• Manually changing paths in both Makefile.conf and Makefile.def

Using with SWMF should be easier out-of-the-box and minimizing the amount of manual editing is highly desirable.

The output directory contains a folder test9, which is for a test that hasn't existed in the version control history that I have access to (i.e., at least since November 2009). This should be removed.

Hi,

I am running RAM-SCB for several days (simulation time) and it sometimes randomly crashes with a segfault. I have found that rerunning the simulation several times until it can finally end is my best solution for right now. I unfortunately cannot make a minimal reproducible example. This was compiled using GSL v2.7. Below is the segfault message and PARAM.in file:

stderr:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x2b713ce7862f in ???
#1  0x2b713ba49cd8 in gsl_spline_init
	at ../../interpolation/spline.c:72
#2  0x5e87db in ???
#3  0x4991c8 in ???
#4  0x4ed8d3 in ???
#5  0x4b950b in ???
#6  0x4918f7 in ???
#7  0x404cb4 in ???
#8  0x404ab6 in ???
#9  0x2b713d0a7554 in ???
#10  0x404ae6 in ???
#11  0xffffffffffffffff in ???

PARAM.in:

PARAM File for Test Week 05 Simulation
Derived from PARAM.in.default

#DESCRIPTION
Test_Week05: 2005-05-12

#EVENT
test_week05_final

************** REQUIRED BLOCK *****************
#STARTTIME
2005					iYear
5						iMonth
12						iDay
00						iHour
00						iMinute
0						iSecond
0.0						FracSecond

#STOPTIME
2005					iYear
5						iMonth
18						iDay
23						iHour
59						iMinute
59						iSecond
0.0						FracSecond

***********************************************

*************** TIMING BLOCK ******************
#MAXTIMESTEP
20.0			MaxHalfStep

#MINTIMESTEP
0.01			MinHalfStep

#VARIABLEDT
T			DoVarDt

#COMPONENT_TIMESTEPS
300.0			SCBTimeStep
300.0			BCTimeStep
300.0			EFTimeStep

***********************************************

*************** COMPONENT BLOCK ***************
#OUTERBOUNDARY
LANL			NameBoundPlasma
T89D			NameBoundMag
MAXW			NameDistribution

#EFIELD
WESC			NameEfield
F				UseEfInd

***********************************************

***************** RAM BLOCK *******************


***********************************************

***************** SCB BLOCK *******************
#SCBFLAGS
F			Isotropic
F			ReduceAnisotropy
T			BetaExtrapolation
F			AzimuthalOffset
F			EmptyLossCone
T			AdaptiveMesh


#SCBSMOOTHING
1			PressureSmoothing
3			SavitzyGolayIterations

***********************************************

***************** INPUT BLOCK *****************
#OMNIFILE
omni.txt		NameOmniFile

#OMNIFILESOURCE
T			UseSWMFFormat

#INDICES_FILE
RamIndices.txt		NameIndicesFile

***********************************************

***************** OUTPUT BLOCK ****************
#SAVERESTART
3600.0			DtSaveRestart
T			DoSaveFinalRestart

#TIMEDRESTART
F			TimedRestartFiles

#LOGFILE
600.0			DtLogFileWrite

#SAVEFLUX
600.0			DoSaveFlux

#OUTPUT_FREQUENCY
-1			DtPressureFileWrite
-1			DthIFileWrite
-1			DtEFieldFileWrite
-1			DtMAGxyzFileWrite

#DUMP3DFLUX
F			DoDump3DFlux

***********************************************

Thank you for your time.

Possible issues:

• Travis CI are migrating everything from their .org domain to .com
• Travis CI have dropped useful OSS support, so we'll likely run out of credits for CI in the not-too-distant future
• Our docker container uses Ubuntu 16.04 (which is now EOL) and GCC5 (which is ancient)

Actions required:

1. Check whether we need to do anything to prevent CI breaking when Travis migrates/shuts down the .org service
2. Consider the long term plan. Probably best to move to github actions, but CircleCI or similar might be a good option
3. Update the docker container to a recent Ubuntu LTS and GCC (probably 9 or 10)

srcExternal includes IRI and GEOPACK. Both appear to be pretty well out of date.

We should probably have a test that engages code calling these, and then we should update to recent versions.
IRI source: http://irimodel.org/IRI-2016/
GEOPACK source: http://geo.phys.spbu.ru/~tsyganenko/Geopack-2008_dp.for

Currently the CI only runs what amounts to test 3. GitHub Actions gives us ~2000 minutes per month for CI and the max runtime of a single container is ~hours.

I'd suggest perhaps switching back to either the "long" CI test or running tests 1 through 3. As long as total test time stays under an hour we should be fine, even during fairly heavy development bursts... ideally we'd run our different tests in parallel and then check test status based on whether they all pass (e.g., the way SpacePy does it)

It's also a good idea to plan out proper unit tests, but expanding the coverage of our regression and integration tests is the low hanging fruit.

Current virtual satellite output NetCDF files make omnidirectional flux variables that are 3D (energy, pitch angle, time), where they should be 2D as the variable is integrated over pitch angle.

The 3D array is created on line 403 of ModRamSats.f90.
It is populated as 2D on line 755 of ModRamSats.f90

@Pheosics : Am I right in thinking this is going to be as simple to fix as changing the dimensionality of the array back to 2D when it's created?