[FEAT] Add high-latitude electrodynamics system

[aaronjridley]

Is your feature request related to a problem? Please describe. Add a high-latitude potential and aurora to the model. These will be sub-models, either empirical or file driven.

Describe the solution you'd like In GITM, this is done where you can choose which sub-model you would like to run. You then set the indices and grid and then ask for the potential or aurora. We should use the same framework. If we can get the fortran code to work, then we don't need to do much. If we want to rewrite to C/C++ that is fine. This is not a computational heavy section of the code, so we can clean it up (i.e., update from Fortran into C++) and it will be much nicer.

Describe alternatives you've considered Figure out how to get the fortran code working and call it good. I already have the sub-model as a stand-alone library, so maybe we just use that to begin with?

Additional context Some of the codes (e.g., Weimer) are written in Fortran anyways, so we will have to get those working.

[aaronjridley]

Created electrodynamics branch to deal with this issue.

[aaronjridley]

I sent this to Rutvik:

One of the things that we may want to do as a first step is write a python code (or find one on the web...) that will read in the omniweb data file in the input directory. I am sure that one of these exists somewhere, but even if it doesn't, it should be pretty easy to write one... Then with the omniweb file read in, we can create and electrodynamics file using the Bz and By in the omniweb file.

It would be good if we could just do something like:

./electrodynamics_write -omni=omni_file.txt -dt=60 -out=output.nc

That is probably a good first step along the way. The next thing we would have to do it make an Electrodynamics class in Aether, which would contain a bunch of private variables, such as: time (1d), latitude (1d), magnetic local time (1d), potential (3d - time/2 space), auroral energy flux (3d), auroral average energy (3d). Then, we need to make a bunch of methods, like:

• initialize (reads the netcdf file and initializes variables)
• set time (tells electrodynamcis what time you want)
• set a 2d grid of desired latitudes
• set a 2d grid of desired magnetic local times
• get potential
• get average energy

• get energy flux

  This is sort of the outline of how to do the electrodynamics stuff....

[aaronjridley]

More info:

The next steps would be to create an electrodynamics class and then start working on methods within the class. I should probably make the class and commit it, and then you could start working on the methods. Somethings that we will definitely have to do:

• Read in the netCDF electrodynamics file, storing the potential, eflux, and average energy into vectors of 2d armadillo matrices, and time as a vector. (Private vars)

• We should write a generic find index routine where you feed in a vector of time and the time you want and you get out a float, where the integer portion is the index of the time before, and the fractional part is the linear distance to go between the two indices. Hmmm.... I wonder if we have this already. Yes, in the indices.cpp, in the Indices::get_index function - it does this, except goes one step beyond and actually does the interpolation. I think that we should break this out into the whole of the aether model and have it as a general tool, but without the final step. I may have made this somewhat confusing. Sorry if it isn't clear....

• A method of set_time should have the current time passed, and then electrodynamics should figure out the current potential, eflux, and avee through one of several methods: linear interpolation in time; nearest time; or last time. This is what is done in the electrodynamics stuff in GITM: GITM/util/EMPIRICAL/srcIE/AMIE_Library.f90, subroutine AMIE_getvalue. Basically, we want to copy this routine.

This is probably a good starting place.

[aaronjridley]

This issue is done, with the incorporation of the electrodynamics branch.