Activity for IRBEM-LIB
-
Antoine Brunet posted a comment on discussion Help
Ok I'll setup the PRBEM/IRBEM-extras repository. I think it's okay to have a simple repository with everything in the extras folder without messing with submodules. Plus this way we can easily preserve the SVN history the same way it was done for IRBEM. I agree with you concerning the github pages, I'll open an issue about this on the IRBEM github.
-
Mykhaylo Shumko posted a comment on discussion Help
My vote is to add the extra code to a https://github.com/PRBEM/IRBEM-extras repo. As for the docs, it will be great to host them online, if we go with Github pages, our url will be irbem.github.io, so it should be easy to find. I am not sure if should dump the HTML into the website repo, or copy the text into a more modern website template such as this one: https://aksakalli.github.io/jekyll-doc-theme/ ? Another option is to use https://readthedocs.org/, but that may be more work.
-
Steve Morley posted a comment on discussion Help
For extras, I'll second (third? since Paul replied while I was typing) the IRBEM-extras repo under the PRBEM group. It's the easy solution and best preserves the ability of anyone looking for it to actually find it. Or we could look into having IRBEM-extras be a repo with submodules, where each submodule is an extras package. That would allow folks to only grab the ones they want and still give a top level repo that has everything (from a user perspective). Least work all round is the basic "move...
-
Paul OBrien posted a comment on discussion Help
Is it possible to create a github.com/PRBEM/IRBEM-extras, and put all the extras there? That's similar to what we did at sourceforge, and I think it makes the most sense. If not, then we should probably make a single separate github repository github.com/IRBEM-extras. Technically, the extras are individual little packages that do their own separate things, and could be their own separate repositories, as you suggest. So, we could have PRBEM/invlib, PRBEM/opendc, PRBEM/nnlib, etc. My only concern...
-
Paul, thanks for pointing this to me. As far as I can tell the extras folder contains separate projects that are not integrated (for now) in IRBEM. If some or all of these projects are still relevant, I see the following options : - Creating a separete github repo for each of the extras projects. These could be under the PRBEM github organization, with a dedicated development team (or the IRBEM-dev github team). - Creating a IRBEM-extras github repo with all the extras. This could be the simplest...
-
Note that right now this migration only includes the /trunk portion of the project. It does not include the extras or docs folders. Those will need to be migrated elsewhere, too. I'm not sure how github structures projects. Can it support multiple packages within a single project? Because the extras and docs are not part of the main library, they're stand-alone things.
-
Hello to all IRBEM contributors, I have tried to send this message to the dev mailing list, but it looks like it's not reaching you. As discussed in the lastest PRBEM meeting, there seems to be a strong consensus towards migrating IRBEM to the Github platform. I am currently setting up a Github Organisation to manage the PRBEM activities on Github, the first of which will be a IRBEM development team and repository. As IRBEM contributors, you probably should be part of this team on the github platform...
-
hevans committed [r635]
updated IDL example to use get_irbem_ntime_max
-
fixed a possible initialization failure in drfit_bounce_orbit
-
Wrapped the get_mlt function and added
-
Fix an import bug in IRBEM.py Coords class.
-
A typo. Added a -e arg.
-
Updated the README install requirements.
-
Removed old files. Still getting used to svn
-
Moved the Python IRBEM wrapper into an inner
-
fixed some 180/pi errors and a couple typos
-
AaronH posted a comment on ticket #10
Hi Paul, On further investigation I think you're right. I had actually tested truncating the result to N=10 and was getting different results, but I now realise that's due to the way that IGRF interpolates the Gauss coefficients (if you don't specify the IGRF initialization frequency, it defaults to the middle of the year rather than the start of the year). I get values much closer if I emulate this. I can try and modify the code to try and implement the full range of coefficients, although I don't...
-
I would guess this is a truncation issue. The ONERA group wrote this bit, I believe. If Sebastien weighs in, we might learn more about why it looks the way it does. If you would like to modify the code to make it cleaner and to conform to the latest / official implementation that is welcome. Be mindful, however, that the truncation was made in order to maintain speed of execution. The library is intended to be a fast code and sometimes sacrifices accuracy to that end. If you do make a modification,...
-
I realise I forgot to specify that the above example was calculated for 2015/01/1, but the year used does not seem to matter -- the values are incorrect regardless.
-
IRBEM IGRF implementation producing incorrect values
-
updated HDF5 cell array variable name description -- zero padding
-
fixed bug in ordering of cell array contents on large cell arrays
-
new routine to write CSV files for isotropic energy response
-
added a short note about the HDF5 3-D response file format
-
added hdf5 support
-
Dillon Gillespie posted a comment on discussion Help
Hi there, So I'm having difficulties using the IRBEM function 'get_Lstar'. I'm trying to make a mapping from the ionosphere (specifically distances around 1.017 Re) to lower L values in the inner-magneto sphere. I ran the following script to call out the Lstar values using the OPQ model. I should note that the intention is to use this for average values and their is no specific date or time I'm looking for. But I do need to keep the coordinates in Re, MLAT, MLT format to Lstar, MLAT, MLT values....
-
Added get_field_multi() to the Python wrapper.
-
Error in conversion between SPH coordinates and RLL coordinates
-
closing for Steve.
-
IGRF 12th have been superseeded by IGRF 13th edition
-
Morley applied the fix and updated the coefficients.
-
I will attempt to close this ticket. I don't know the actual reason for truncating the IGRF. But, since IRBEM was built to be fast, it could be that the ONERA team decided they didn't need those extra terms. Or, it could be they just copied whatever GEOPACK had. We know from the old Olson-Pfitzer study that one need not evaluate all the IGRF terms to get an accurate L value. But, for just computing B at the surface of the Earth, those details would presumably matter.
-
For anyone else running into this error, the following will work around the error that Adam mentioned in the previous post without explicitly providing a myownfield_init function: In the file source/init_nouveau.f, comment out line 58, In the file source/onera_desp_lib.f, comment out lines 1267 and 1284 Remake the library. As long as you don't use the "own field" functionality, the library should work without issue now.
-
Hi Thomas, Thanks for the patch. I'm not part of the core development team, so hopefully my commit access will be deemed as having been used for good here. This has been applied in r620. I can't speak for the IRBEM developers on why the additional coefficients aren't used where they are available. If you do need the functionality provided by IRBEMlib, but need the additional precision, and aren't tied in to using Fortran - then take a look at LANLGeoMag (https://github.com/drsteve/LANLGeoMag). There's...
-
Update DGRF/IGRF to 2020. Patch from T. Nilsson. Closes #9.
-
Change made in r619. I don't think I have permissions close this ticket though...
-
Change made in r619
-
Correct radius assignment in SPH to RLL conversion. Closes issue #8.
-
Thomas Nilsson modified a comment on ticket #9
Since there has been very little progress on this more or less trivial issue, I took the liberty of creating a proposed fix (attached here as a diff file) in case it can be of any help to anyone. With best regards, Thomas Nilsson, IRF Uppsala edited 2020-02-21T10:45 CET: Removed incorrect attachement file, see comment below
-
Dear everyone, I was just made aware of a typo which snuck into my proposed "igrf_coef.f.diff" file which was linked above. One line, which added: +2020 F2=(year-2020.D0)/5.D0 instead should have read: +2020 F2=(year-2015.D0)/5.D0 Please consider using the corrcted "igrf_coef.f.diff" file which is attached in this message instead. And my appologizes to anyone who downloaded and used the previous incorrect verison. Credit goes to Nikolai Pavlov for catching this and making me aware of it, thanks again!...
-
As all of you may noticed, in my suggested patch (igrf_coef.f.diff) I simply followed suite in regards to only having the main-field coefficients of the IGRF up to degree N=10. This was done to ensure it did not introduce unexpected bugs in other parts of the IRBEM-LIB codebase, which I am not too familiar with, (in particual igrf.f). However now I must simply ask, why does not IRBEM-LIB take into account the full IGRF model which, since IAGA's decision in 2001 (which is referenced in text here https://doi.org/10.1111/j.1365-246X.2005.02641.x),...
-
Since there has been very little progress on this more or less trivial issue, I took the liberty of creating a proposed fix (attached here as a diff file) in case it can be of any help to anyone. With best regards, Thomas Nilsson, IRF Uppsala
-
IGRF 12th have been superseeded by IGRF 13th edition
-
Alexander Lozinski posted a comment on discussion Help
Hi Paul, thanks very much for your explanation, that makes sense now Kind regards
-
Alex, IRBEM only does guiding center calculations. So, we can't generate cyclotron motion. As for R0, the idea is that sometimes you might want to trace trajectories below the surface of the Earth. When R0=1, the tracing aborts any time it hits the Earth's surface (r <= R0). But, because the tracing involves some searching along the field line for the mirror point, it can also abort inadvertently if the search goes below surface. So, it's often best to try R0=0.8 or R0=0.9 to allow some margin in...
-
Dear all, I recenty began using IRBEM with Fortran to plot bounce paths using DRIFT_BOUNCE_ORBIT. I have two questions: 1) I would like to calculate the full trapped particle trajectory including gyromotion. Am I correct in thinking that DRIFT_BOUNCE_ORBIT can only calculate the bounce path of the gyrocentre? I can create plots like those attached. I also have my own code that solves the Lorentz equation for a particle at a given mu, L and alpha, but it is very slow and I would like to validate the...
-
Error in conversion between SPH coordinates and RLL coordinates
-
added python version of odc_util
-
moved inline comments on statement lines for f2py compatibility
-
Updated the external models look up table.
-
magfields_tests_and_visualizations.py: Fixed a small output name bug.
-
Added python documentation.
-
moved inline comments to fix python wrapping with f2py
-
Adam Kellerman posted a comment on ticket #7
When calling the code, I get the following error "undefined symbol: myownmagfield_init", So I guess we are missing a file?
-
Correction: Not deleting the line, but removing the 'myOwnMagField' commands on line 359 of the Makefile - so that it reads "all.build: version.fortran ntime_max compile_irbem" - get's around the error.
-
Make file fails with new 'myownmagnetic field' options
-
fixed another shieldose target abbreviation
-
added target material options
-
Jongkil Lee posted a comment on discussion Help
Using make command, I try to install IRBEM LIB. But cant create correcty. My system is Linux64, intel fortran64. So my command is make OS=linux64 ENV=intel32 all Building non-sharable object onera_desp_lib_linux_x86.a AFRL_CRRES_models.f(525): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'. read(10,'(34(D9.3,1x))')(flux(e,k,ish),k=1,34) ------------------------------^ AFRL_CRRES_models.f(543): remark #8291:...
-
Avoid hard coded IGRF coefficents, read from text file in environment variable "IGRF_COEFFS".
-
sync
-
modified mks.RE (km) to mks.R_E (m). This affected odc_DLL_Ozeke2012.m which may have had a km/m error. It's a bit of a mystery, since w/o the fix, the test wouldn't have passed. Clearly it did. mysterious.
-
s-bourdarie committed [r608]
Memory error fixed in find_mirror_point1
-
Added the possibility to compile my_own_mag_field.f routine by provide path to access the source file in case it is not included in IRBEM/source directory
-
adding PDF version of RFL lib doc
-
removed ts07d target
-
Added the newer July 2017 TS07d model to kext 14, added new geopack_08, revised makefile, init scripts to remove the ts07 include file - we now rely on the global variable. Revised the ts07d setup script. removed geopack routines from the ts07d-2015 file. Note that the 2015 and 2017 versions of the TS07 model both include the Bessel function optimizations from JA. The former had them previously implemented in a separate file, now renamed to TS07j_2015.f. The 2015 model can now be found in Tsy...
-
sync
-
Added a local pitch angle parameter to the bounce_period calculator.
-
Cleaned up the code comments
-
Adjusted the package info variables to comply with Python's
-
sync
-
Fixed the function output names to be consistant.
-
Moved the IRBEM class to MagFields in the IRBEM.py file. Added a Coords class that wraps the coordinate transform functions in IRBEM FORTRAN code. Lastly, added test scripts for the two classes.
-
Updated coord_trans_vec description where ECI_TOD and J2000 coordinates have been added
-
Sync
-
Sync
-
Minimum energy in AE8 set to 40 keV instead of 50 keV.
-
Tab change to spaces (better with eclipse/fotran)
-
Tab change to spaces (better with eclipse/fotran)
-
Tab change to spaces (better with eclipse/fotran)
-
New file
-
Tab change to spaces (better with eclipse/fotran)
-
Added a if statement to test if user is using mac osX to load a mac-specific shared linrary. Same thing for Windows, but has not been tested!
-
Fixed the naming nominclature so now the function output
-
Made checks for arrays more Pythonic and fixed the Lstar dictionary key.
-
Added the functionality for the user to choose the external model by name from
-
Changed the STATUS_FLAG keyword to verbose.
-
Updated comments, and added the verbose keyword, which used to be called
-
Updated the test suite to run all of the tests when called with
-
Added package information to IRBEM, and added a setup script in setup.py
-
Added a check for magnetic field model paramete...
-
Fixed a bug with make_lstar modifying the input...
-
Reorganized functions so that the "protected" f...
-
Added two functions that utilize IRBEM to calcu...
-
Added a warning message if more than 50,000 ele...
-
Added a little bit of user firendliness to the ...
-
Fixed comments
-
find_magequator function seems to work, so I re...
-
Made helper functions in IRBEM.py "private". Wr...
1 >