[PD] VASP future

Thomas Grill gr at grrrr.org
Tue Mar 22 21:58:19 CET 2005


Hi all,
i'm thinking about the future of VASP these days since i'm myself using 
it for compositional work.
Said this, it is not completely true though, since i'm using the 
numarray extension of the py/pyext external (CVS version), which allows 
to work with PD arrays in Python. I consider this the future of VASP 
(namely to be a pure Python module), although it will perhaps be called 
differently then.
Realizing there are still a number of daily downloads although i haven't 
touched VASP for quite a while now let's me ask you about your usage of 
VASP. Do you use it for
- simple array math/transformation?
- medium complex things like analysis or synthesis?
- complex work like algorithmic composition and the likes?
- none of the above?
- something completely different?
Does it have to provide
- real-time response (like for interaction with DSP processing)?
- or not?
Do you predominantly use
- singular VASP objects?
- groups/whole subpatchers of interacting VASP objects?

I realized in my own work that it's very hard to express complex stuff 
as PD graphs, and also VASP has the problem of needing to lock arrays 
while working on them, which still isn't really implemented in PD (it is 
in the devel branch, but the future of this isn't clear either).
The question is now whether i abandon the current PD object 
implementation of VASP and focus on the Python one, or think about a 
side-by-side solution of both systems, probably reducing the 
functionality of the current VASP implementation a bit. There's still 
time to decide since the Python array implementation hasn't been 
standardized yet....
Let me know what you think and if you care at all.

best greetings,
Thomas





More information about the Pd-list mailing list