Initial support for loading NLD/GSF from disk

[vetlewi]

I've added a static method to the Extractor class that will allow the user to load an existing ensemble of NLD and gSF from disk. This will eventually close issue #138.

At the moment there are some issues that will need to be resolved before ready for merging:

• Determine that the state of the object is valid
• Write unit tests for the load method

[fzeiser]

There seems to be some confusion: There was a load method, but I removed it in 32572d5. The results are anyhow loaded in extract_from, if the regenerate flag is set. However, I guess following line should be updated then:

ompy/ompy/extractor.py

Lines 34 to 35 in 0fba72a

	self.nld and self.gsf, as well as saved to disk. The saved results are
	used if filenames match, or can be loaded manually with `load()`.

The cleanest alternative would be to refactor the code to have a clear load and save function that is used and not two alternative implementations for the same goal. However, I guess I was just too lazy to do something about it last time [at least it's not a broken functionality].

[fzeiser]

• I agree that the pull request makes sense. However, in the current scheme there is still a doubling of the load and save methods:
  

  ompy/ompy/extractor.py

  Lines 131 to 143 in dd10550

  	for i in tqdm(range(self.ensemble.size)):
  	nld_path = self.path / f'nld_{i}.npy'
  	gsf_path = self.path / f'gsf_{i}.npy'
  	if nld_path.exists() and gsf_path.exists() and not regenerate:
  	LOG.debug(f"loading from {nld_path} and {gsf_path}")
  	nlds.append(Vector(path=nld_path))
  	gsfs.append(Vector(path=gsf_path))
  	else:
  	nld, gsf = self.step(i)
  	nld.save(nld_path)
  	gsf.save(gsf_path)
  	nlds.append(nld)
  	gsfs.append(gsf)

• If you want to continue on this issue, I'll also put in a flag that this should be metnioned in the release notes (potentially incompatible loading old data).
• if one removes the trapezoid (...) from the call syntax one probably has to adopt the "getting stated" notebook

[vetlewi]

• I agree that the pull request makes sense. However, in the current scheme there is still a doubling of the load and save methods:
  

  ompy/ompy/extractor.py

  Lines 131 to 143 in dd10550

  	for i in tqdm(range(self.ensemble.size)):
  	nld_path = self.path / f'nld_{i}.npy'
  	gsf_path = self.path / f'gsf_{i}.npy'
  	if nld_path.exists() and gsf_path.exists() and not regenerate:
  	LOG.debug(f"loading from {nld_path} and {gsf_path}")
  	nlds.append(Vector(path=nld_path))
  	gsfs.append(Vector(path=gsf_path))
  	else:
  	nld, gsf = self.step(i)
  	nld.save(nld_path)
  	gsf.save(gsf_path)
  	nlds.append(nld)
  	gsfs.append(gsf)

Refactored. There should also be written a unit test for the methods. Will do it before pull.

[vetlewi]

I think that before merging this PR there should be a super class defining the save/load syntax.

Probably something like

class LoadSaver():
    def __init__(self, path: Union[str, Path]):
        if path is not None:
            self.path = Path(path)
            try:
                self.load(self.path)
            except ValueError:
                self.path.mkdir(exist_ok=True, parents=True)


    def load(self, path: Optional[Union[str, Path]] = None):
        raise NotImplementedError


    def save(self, path: Optional[Union[str, Path]] = None):
        raise NotImplementedError

and require the subclasses to implement load() and save().

[fzeiser]

Thanks for implementing the abstract loadsaver. I guess we should then make Extractor (and the normalizers) subclasses of abstract_load_saver

[vetlewi]

Thanks for implementing the abstract loadsaver. I guess we should then make Extractor (and the normalizers) subclasses of abstract_load_saver

I've now made Extractor a subclass of the abstract_load_saver:

The ensemble class will require some refactoring, while the normalizers already has something similar built in the abstract_normalizer, which could be a subclass of the abstract_load_saver.

I'm not sure I want to do that much refactoring... Need to do prioritize the actual analysis I'm working on :/

[vetlewi]

I don't think I will be working much more on this PR anytime soon. Maybe just merge and then create an issue noting that other classes needs refactoring to use AbstractLoadSaver?
Or maybe not... I can always PR to a branch in the fork on my own GH when I need it... :p