copy method in HMM

[yumengch]

The pull request relates directly to the issue #20

Key changes:

• Add a copy method to class HiddenMarkovModel using copy.deepcopy.
• Substitute HMM import in all examples/tests/mods to assignment with the new copy method.
• Remove --ignore-glob=dapper/mods/Lorenz* in pyproject.toml.

Response to some comments;

• You'd probably need to use deepcopy, though. Otherwise the changes in eg dapper.mods.Lorenz63.wiljes2017 to HMM.t will also be present in the copy of the HMM.

Done

• IIRC, copying can run into trouble because objects cannot be pickled. However, this is already a consideration for multiprocessing, and hasn't yielded much trouble ever since I started using dill (via multiprocessing_on_dill).

copy indeed relies on pickling. However, as far as I can see, current use of HMM doesn't run into such problem. If any issues arise in the future, I think we can always use a customised copy. For the time being, I think the copy module is sufficient.

• This might have the unintended consequence that changing the forcing (e.g dapper/mods/Lorenz96/pinheiro2019.py) does not take effect. I'm not sure though.

I'm not so sure about the problem, but I checked that the following short test run uses F=8.17.

from dapper.mods.Lorenz96.sakov2008 import HMM as _HMM
import dapper.da_methods as da
import dapper.mods.Lorenz96 as model
HMM = _HMM.copy()
model.Force = 8.17
xx, yy = HMM.simulate()

I hope this resolves your concern? The real issue for the model force, I think. is that we always have to manually reset the force if we change it. I think this might be an argument for using an OOP style model...

[patnr]

Excellent!

I hope this resolves your concern? The real issue for the model force, I think. is that we always have to manually reset the force if we change it. I think this might be an argument for using an OOP style model...

Yes, pretty much. And yes, OOP is more flexible & robust. But also more daunting for a beginner. I think L63 and L96 should not use OOP.

Related: I will add this TODO: Move documentation from L63 and L96, which is in the form of code comments, into its own doc page (maybe mods/__init__.py).

• Expand upon these comments. For example:
• Note that OOP (exemplifed with QG, LUV, etc) is more flexible & robust, and therefore better suited when different parameter settings are to be investigated. Caution: for parameter-estimation, the parameters are input variables to the "forward model", which does not necessarily require OOP.
• Note that the mod settings files do not keep a very high programming standard.
• Note that HMMs can be copied to create new settings.
• Note pitfalls (eg changing Force)
• To simplify L63 even more for beginners, move d2x_dtdx, dstep_dx, and LPs from mods/L63/__init__.py into mods/L63/extras.py ?