[TangerineSDR] IGRF Python Package

[Stephen Roland Kaeppler]

Hi All-

As an update, I am going to need to look for where the code is located.  A couple of other subtle but important points:
1. There is some C-code associated with this which needs to be compiled, I believe.  I did this for speed.
2. I seem to recall that sometimes the code would seg-fault.  I know this is a problem, but I never really tracked down what the issue was.
3. Important - the code is written to output magnetic field in Br, Btheta,Bphi.  So if we need to rotate that into a different coordinate system, let me know...

Finally, I can git init a repo and then make commits to that local repo.  The question at that point is what you guys want me to do with it?  Do you want me to send you an archive copy or put it up on my github?  Let me know what you all want...

Thanks,
Steve

------------------------------------------------------------
Stephen R. Kaeppler, Ph.D.
Assistant Professor
Department of Physics and Astronomy
Clemson University
Clemson, SC 29634
Email: skaeppl at clemson.edu
Phone: 864-656-4275
Web: http://science.clemson.edu/kaeppler/
Amateur Radio Callsign: AD0AE
------------------------------------------------------------
 

On 4/1/20, 9:37 PM, "Rob Wiesler" <robert.wiesler at case.edu> wrote:

On Wed, Apr 01, 2020 at 11:50:22 -0400, Phil Erickson via TangerineSDR wrote:
>   I strongly recommend that this project
>
> a) use revision control
> b) host its own SVN / git / etc. server
>
>   Relying on things like GitHub is not safe in the long term, because
> corporate decisions can change abruptly on what is offered free to the
> community and what is not.  Also, many of the "free" services make
> absolutely no guarantees about where any of the data is backed up, what the
> backup schedule is, etc.
>
>   I relate these pieces of advice from painful experience at MIT Haystack.
> Our group believed Dropbox when they rolled out a storage plan with very
> large upper bound limits for MIT.  A couple years ago, they abruptly
> cancelled that policy and assigned a very large per year fee for the
> storage we had been using.  I'm still trying to figure out how to extract
> 100s of TB of data from them, and some of it may be lost for good.

I can't agree more.  It is trivial to set up git hosting outside of
corporate-hosted sites, and nearly free.  There are many, many ways to
do this.  As it often is, the trick is to go with the oldest thing that
people still use.  I think cgit looks nice.  Personally, since I don't
need a web frontend, my own systems use a simple Python script I wrote a
while back that hooks into incoming SSH connections for the "git" user.

In addition to disrecommending Github, I would like to mention that
hosting one's own Gitlab instance is a pain in the neck.  Gitlab has
made their software nearly impossible for distributions to package,
which means you're not getting security support without continually
upgrading to the bleeding edge, which means things break often.  Quoting
from their Releases page: "GitLab has been releasing on the 22nd of the
month for the last 102 months straight!".  Good luck keeping that mess
up-to-date as a volunteer.

The other thing to consider is that we want to package everything we use
for Debian.  I think I've already convinced everyone this is a good
idea, so I won't reiterate the reasons.  I think that suggests a good
desiderata for what software to publish in git - if we can stand to
maintain a package for the operating system we plan to distribute, we
keep it.  If not, it's not really appropriate to spend our (the
TangerineSDR/PSWS projects) time on it.