[Cppqed-support] trajectory design for python I/O

[Raimar S. <rai...@ui...>]

On Friday, November 15, 2013 08:35:49 PM you wrote:
> > Finally, I am currently in the process of porting my python I/O branch to
> > the
> > current development branch. I have thought about splitting everything
> > which is
> > necessary and sufficient to define a trajectory state and the methods to
> > read and
> > write it into a new class (or new classes). The goal here is to create a
> > minimal non-virtual base class that can be easily instantiated in the
> > python
> > code, not hijacking the Simulated class for this purpose. But I'm not yet
> > sure
> > how to do the split in practice, as it goes through both the Trajectory
> > and
> > Evolved, respectively. Do you think this is the right way to go?
> 
> I agree to the split, but please make sure that it doesn’t seriously upset
> the design (and usage) of the Trajectory bundle, which I like a lot. Are
> you sure that Evolved should also be split? Because Evolved proper is a
> template?

Dear András,

I might need a little bit of assistance here. I have pushed the current state 
to the cppqed/core repository on the group server (subject to rebasing at any 
time).

git remote add private an...@ge...:git/cppqed/core
git fetch private
git checkout cpypyqed

This is essentially the current state as we left it at my Budapest visit, only 
updated to the current Development branch.

The problem which I am facing is that I need a class which I can instantiate 
in the python module io.cc, which cannot know anything about an actual system. 
We want to be able to take a numpy array and write it into a state file with 
the interface presented by Trajectory. For this we need a non-virtual class 
which inherits from Trajectory and has the Evolved as member. This is 
basically a wrapper class for the array which provides the functions for 
reading and writing. Up to now the DummyTrajectory class takes this role, 
inheriting from Simulated. Although this works it is of course not a nice 
design.

One possibility would be to inherit from Adaptive and implement all the 
virtual functions with no-op functions. But I also don't like this solution: 
the wrapper dummy class is not intended to be evolved or used in simulations 
in any way. For the same reason using a full-blown Evolved member with the 
derivs and all other parameters which are not written to the state file feels 
like overkill. Having this in mind it would be reasonable to not even let it 
inherit from the full trajectory class and include a full Evolved, which is 
why I wanted to split the data from the logic to evolve it. But that would 
probably involve some major design changes, and I cannot and don't want to do 
this without further discussion.

So maybe you have an idea how to approach this in an elegant way, or we could 
skype to resolve the issue? The lack of python I/O hinders me (and probably 
the others from my groups) from using the new Development branch in 
production, as all my postprocessing scripts depend on it.

Best regards
Raimar