wavepacket-user — List for users to get help and whatever they might need

Re: [Wavepacket-user] help

[Ulf L. <ulf...@de...>]

On Fri, 2011-03-25 at 21:05 +0800, Jijun Xu wrote:
> I downloaded the wavepacket software package from sourceforge. The
> package is very excellent. I tried to study it and use it. But I
> encountered a problem, how can i store the wave function every step
> when I use qm_propa to calculate the time-dependent equation. I read
> the manual, and tried to add
> "psi.save.export=true;psi.save.dir='dir';psi.save.file='file.dat';psi.save.step=n" in the initialize.m, but the program cannot run normally.
> would you mind give me suggestion? Thanks for your help!

>From the top of my head, what I can think of:

1. Does the directory 'dir' exist? I just checked that you should get
   an error if not.
2. Is there enough space left?
3. psi.save.file does not require the suffix '.dat', this is appended 
   by the program. If you use Windows, it might get confused about two 
   dots in a file name, but this is more of a speculation.
4. The product
       (total number of grid points) * psi.save.step * 16
   should be smaller than your total memory in bytes (maybe smaller 
   than half of your memory, but that depends on some details of
   Matlab's memory management that I do not know), because Wavepacket
   first accumulates all the saved wave functions in memory before
   writing them out. However, with normal setups (swap space), not
   doing this should "only" lead to a horrible performance, not to an
   error.

If these quick suggestions do not help, then I would ask you to provide
a bit more information:

a) Which WavePacket version do you use?
b) What exactly is the problem. If there is an error message, what is 
   the error message?
c) Does the problem also occur if you take one of the small demos, for 
   example, Demos/HarmOscillator/Gaussian_1D/1, and add saving?
d) If you used a custom setup, could you send me the files that are 
   required to run the calculation?


Ulf

[Wavepacket-user] help

[Jijun Xu <ji...@gm...>]

I downloaded the wavepacket software package from sourceforge. The package
is very excellent. I tried to study it and use it. But I encountered a
problem, how can i store the wave function every step when I use qm_propa to
calculate the time-dependent equation. I read the manual, and tried to add
"psi.save.export=true;psi.save.dir='dir';psi.save.file='file.dat';psi.save.step=n"
in the initialize.m, but the program cannot run normally.
would you mind give me suggestion? Thanks for your help!

Re: [Wavepacket-user] Coulomb problem

[Lorenz, U. <ulf...@de...>]

One correction , and one addon:


> On Wed, 2010-10-20 at 17:38 +0800, wanglei365x wrote:
> > Hello,
> > 
> > I am trying to solve the  hydrogenlike Coulomb problem in Fourier
> > method. The wave function has the boundary condition fai(0)=0. So i
> > have to double the grid over to the negative r side.  When implement
> > the 'wavepacket', in this r range, the grid_fft grid contain a grid
> > point 'r_i = 0', this make the Coulomb potential divergence. And the
> > choice  of value of the variable 'hamilt.truncate' makes significant
> > influence to the result. Is this problem existence in the 'wavepacket'
> > and how can i set the value of the variable 'hamilt.truncate'(the
> > estimate Coulomb potential is divergence near the origin)

I have not quite understood which problem you solve how: Do you have the
3D Coulomb problem after separating the angular coordinates (which would
leave you with an effective 1D Coulomb problem)?

> You can use a soft Coulomb potential, i.e., replace V(r) = 1/r^2 by
> something like V(r) = 1/(r^2 + a^2), which provides a smoother
> truncation than just setting hamilt.truncate to some value.

The Coulomb potential is of course 1/r, and the soft potential was probably
1/sqrt(r^2 + a^2) for some constant a.


Ulf

Re: [Wavepacket-user] Coulomb problem

[Ulf L. <ulf...@de...>]

On Wed, 2010-10-20 at 17:38 +0800, wanglei365x wrote:
> Hello,
>  
>    I am trying to solve the  hydrogenlike Coulomb problem in Fourier
> method. The wave function has the boundary condition fai(0)=0. So i
> have to double the grid over to the negative r side.  When implement
> the 'wavepacket', in this r range, the grid_fft grid contain a grid
> point 'r_i = 0', this make the Coulomb potential divergence. And the
> choice  of value of the variable 'hamilt.truncate' makes significant
> influence to the result. Is this problem existence in the 'wavepacket'
> and how can i set the value of the variable 'hamilt.truncate'(the
> estimate Coulomb potential is divergence near the origin)

It is a while ago that I have last seen the Coulomb problem, but as far
as I remember, there are two approaches.

You can use a soft Coulomb potential, i.e., replace V(r) = 1/r^2 by
something like V(r) = 1/(r^2 + a^2), which provides a smoother
truncation than just setting hamilt.truncate to some value. This
potential has AFAIR a few properties that were different from the raw
Coulomb potential, but I do not recall which. I also remember that this
was sort of the standard first approach one often sees in strong-field
ionization.

I also remember having seen also something called scaled Fourier method
or so that was said to be useful for the raw Coulomb problem, but I have
no idea where. Probably one of the Big Guys (e.g., Kosloff, Tannor) has
published something in this direction, and it is on my eternal list of
things to look up one day. In any case, this method is not implemented
in WavePacket.


Does this help?

Ulf

[Wavepacket-user] Coulomb problem

[wanglei365x<wan...@16...>]

Hello,

   I am trying to solve the  hydrogenlike Coulomb problem in Fourier method. The wave function has the boundary condition fai(0)=0. So i have to double the grid over to the negative r side.  When implement the 'wavepacket', in this r range, the grid_fft grid contain a grid point 'r_i = 0', this make the Coulomb potential divergence. And the choice  of value of the variable 'hamilt.truncate' makes significant influence to the result. Is this problem existence in the 'wavepacket' and how can i set the value of the variable 'hamilt.truncate'(the estimate Coulomb potential is divergence near the origin)

2010-10-20



wanglei365x

Re: [Wavepacket-user] questions about the wavepacket

[Ulf L. <ulf...@de...>]

On Wed, 2010-10-20 at 10:35 +0800, wanglei365x wrote:
> hello,
> i am one of the wavepacket-users, i am confusing about the following
> questions: 

Great, feedback. :)

> what does the variable 'hamilt.truncate' mean, why we need it, and how
> to decide it?

The variable used to be more central, and is admittedly hard to follow
in the code flow. However, it still has two uses:

1. Less important: When plotting, in the absence of other parameters, it
is used to select some energy ranges for the plot. However, there are
other variables nowadays, which are not really documented and sometimes
do the same (making developing note).

2. For the Chebychev propagator to converge, all eigenvalues of the
Hamiltonian must be in a finite range [min,max]. Furthermore, the
propagator is faster (allows larger time steps with the same accuracy
and cost) the smaller the range delta = max-min is. In this case,
hamilt.truncate.{min|max} is used to truncate the potential and kinetic
energy grids so that they are guaranteed to have eigenvalues in the
range [min,max] (potentials) or [0,delta] (kinetic energy). Then the
bounds are added to give a worst case estimate of the smallest and
largest eigenvalue of the total Hamiltonian (stored in hamilt.{min|
max}), which you can override if you know better.

If you normally use the split operator and do not care too much about
the plots (or fiddle around with them using plots.pot.{min|max}) then
you can ignore this variable. If you set it, set it such that the
important part of the potential and kinetic energy is safely within the
boundaries.


Ulf

[Wavepacket-user] questions about the wavepacket

[wanglei365x<wan...@16...>]

hello,
i am one of the wavepacket-users, i am confusing about the following questions: 

what does the variable 'hamilt.truncate' mean, why we need it, and how to decide it?

i am looking forward your reply.

2010-10-20



wanglei365x

Re: [Wavepacket-user] WavePacket-4.7.2: wav_morse.m

[Ulf L. <ulf...@ke...>]

On Thu, Sep 23, 2010 at 03:12:50PM +0200, Jakob Petersen wrote:
> In lines 11 and 16 the range parameter is denoted ae. From line 49 and
> on, the range parameter is denoted alf.

Fixed. (along with some other inconsistencies; maybe we should clean up
the comments some time).


Ulf

[Wavepacket-user] WavePacket-4.7.2: wav_morse.m

[Jakob P. <pet...@gm...>]

In lines 11 and 16 the range parameter is denoted ae. From line 49 and on,
the range parameter is denoted alf.

-- 
Best regards,
Jakob Petersen
pet...@gm... | (+45) 31 24 79 73

[Wavepacket-user] WavePacket 4.7.3 released

[Ulf L. <ulf...@ke...>]

Hello,

a new maintenance release is out. As discussed some time ago on the user
mailing list, it features some new ways to create the animations.
>From the changelog:


* added ability to create movies without graphical interface by
  "printing" the plots to jpeg files

* added qm_movie script to create movies from a saved calculation

  see
  http://sf.net/apps/mediawiki/wavepacket/index.php?title=WavePacket4.Advanced.Movies
  for a description of the new features

* various licensing fixes:
	- added required headers to source code files
	- added explicit exception for distributing WavePacket without Matlab
	- made all demo files public domain

* bug fixes:
	- qm_bound crashed in various places if only excited states were used.
	- fixed a memory leak when plotting expectation values
	- wav_load now uses psi_load instead of duplicating its obsoleted wrong
	  code



This might be an opportunity to remind everyone that suggestions about
what to do next are welcome and will be implemented relatively fast.
Optimal control is currently next on the TODO list.


Ulf

Re: [Wavepacket-user] Any wishes for 4.7.3 ?

[Ulf L. <ulf...@ke...>]

On Wed, Jun 16, 2010 at 12:36:51PM +0200, Ulf Lorenz wrote:
> On Wed, Jun 16, 2010 at 11:36:16AM +0200, be...@ch... wrote:
> > Another point is the possibility of creating movies in a non-interactive
> > way, i.e. to let run qmpropa in a queue, where a movie is created in a
> > file, which can be looked at after the job finished. I think today, one
> > always has to run the program interactively and to shut down the
> > screensaver to make a movie of the wavepacket propagation.
> 
> The problem here is that the way Matlab creates a movie is letting you
> paint the image, then making a screenshot. I can have a look around if
> there are packages that have a different approach, but I would not count
> on it.

Update: Had a look around today, and it does not look very promising. I
have fixed one error in the calculation of some sizes, so that you can
at least output _images_ in non-interactive mode (this works by
"printing" them), but movie generation still relies on getframe(), which
in turn makes a screenshot.

I think I will add an option to output the single frames as individual
images, though. Then you could put together the movie yourself using
ffmpeg or similar.


Ulf

Re: [Wavepacket-user] Any wishes for 4.7.3 ?

[Ulf L. <ulf...@ke...>]

On Wed, Jun 16, 2010 at 11:36:16AM +0200, be...@ch... wrote:
> Hello Ulf

Hi,

I just assume you do not mind if I make this public (if you do, write me
an angry email and I will stop).


> Thank you for your advises. You asked for wishes for the new version of
> wavepacket (for a higher acceptance in the research).
> One wish would be the implementation of optimal control. Some years ago I
> already implemented a simple Tannor scheme for forward and backward
> propagation. Since now backward propagation is directly possible, it
> should be possible as well to implement Optimal Control in the wavepacket
> program to compete with the MCTDH package, were this is already
> implemented.

Good point. The idea has been around for quite some time, and I think we
(at least I) never implemented it because it is a bit cumbersome to do
in the stable branch. Essentially all the ideas we had included hacking
qm_propa in a most ugly way.

However, if I remember correctly, the only really missing functionality
is the ability to do some custom calculations during the propagation.
This can be implemented in principle (add a function reference that gets
called at each main time step), and the other obstacles can be overcome
with some scripting...

In short: Added to the TODO. It will result in a not too elegant hack
(something like the scripts for explicit pump-probe calculations, see
http://wavepacket.sourceforge.net/Demos/FemtoChem/Interferometry), but
it should be possible to write a script that can be applied to general
problems.


> Another point is the possibility of creating movies in a non-interactive
> way, i.e. to let run qmpropa in a queue, where a movie is created in a
> file, which can be looked at after the job finished. I think today, one
> always has to run the program interactively and to shut down the
> screensaver to make a movie of the wavepacket propagation.

The problem here is that the way Matlab creates a movie is letting you
paint the image, then making a screenshot. I can have a look around if
there are packages that have a different approach, but I would not count
on it.

However, the qm_movie script might be able to circumvent this problem.
With this, you would do the calculations on the single nodes
non-interactively (turn plotting off), save the results, and then use
the qm_movie script afterwards to extract the films from the
calculations (which requires interactive access, but goes relatively
fast).

This still poses problems if your calculations are too large to be
saved, though. Is this the case for you?


Regards,
Ulf

[Wavepacket-user] Any wishes for 4.7.3 ?

[Ulf L. <ulf...@ke...>]

Hi,

after the release of the tech demo, I thought I would spend some time on
the stable 4.7 branch. Now the roadmap I came up with is pretty lame. It
consists of

* some copyright issues (adding copyright notices to the files, plus
  some other minor things that we have not done yet)
* adding a qm_movie script that produces a movie from a saved
  calculation.


Do you have any wishes that you would like to see implemented for the
next release?


cu,
Ulf

[Wavepacket-user] Version 5 Techdemo 2 released (unstable)

[Ulf L. <ulf...@ke...>]

Hello everyone,

I just want to announce some progress with the development version of
WavePacket. It is still unstable, and of little use (only harmonic
oscillators implemented so far), but slowly getting into shape.

If someone wants to try this out to see where we are headed, you can
download it from http://sourceforge.net/projects/wavepacket/files/.

I might add that if someone is eager to contribute, there is a lot of
also relatively easy work to be done when it comes to translating all
the standard potentials etc. from the WavePacket 4 code base.


The more detailed list of changes:

* made code compatible with Matlab Release 2008a (version 7.6)
* added a rudimentary manual (found on the Wiki)
* added collection operators (sums, products), and formal algebra
  (i.e., the line "A+B" creates a sum operator that holds the
  operators A and B)
* collection operators can be left for keeping the structure of an
  operator, or packed to speed up evaluation
* implemented a general grid operator that does what the *.grid_ND
  variables were used for in WavePacket 4
* added collections (sum/product) and formal algebra for initial
  wave functions
* added a "manual" propagation mode, where you supply the wave
  function and step size to an operator, propagate for some steps with
  the ability of modifying the wave function, propagating backwards etc.
  as you go
* added suppressible output to init functions
* optional parameters are parsed using inputParser
* removed global variable "const" and renamed the others
* started implementing standard comment scheme and unit tests
* removed various superfluous arguments to functions, made others mandatory
* added display function to base classes (output when not suppressed with
  semicolon)
* added custom function for zeros, cell, ones
* a lot of cleanup and smaller interface changes



Ulf

[Wavepacket-user] WavePacket 4.7.2 released

[Ulf L. <ulf...@ke...>]

Hello everyone,

we are pleased to announce the next maintenance release of the stable
WavePacket branch. Changes compared to the last release:


* minor rewrite of how laser pulses are handled;
    - interpolation of electric fields is now more flexible
	- added linear and quadratic chirping

* interpolating the electric field outside the given time range
  now gives zero field

* NaI potential/dipole got a parameter "R_dof" to specify the
  radial degree of freedom

* added demo that demonstrates chirping, and time-dependent
  projection on Morse eigenstates (VibExcite/Chirp)

* bug fixes:
	- fixed an error in the convergence script
	- fixed an incorrect scaling factor when transforming to different
	  grid sizes (FFT grid)
	- wave function was always saved to two different files
	- fixed a bug that prevented loading if the wave function is saved
	  to multiple files
	- fixed bug #2861295 (last expectation value empty) by saving the
	  wave function after everything else
	- fixed bug #2860763 (Chebychev diverges); Chebychev in imaginary
	  time now rejects too large, numerically unstable time steps


If you have ever used the feature of interpolated electric fields, this
is no longer compatible with this version. You no longer interpolate the
whole electric field, but specify the pulse shape to be 'inter'
[-polated]. This is more flexible, but needs some more parameters; see
the reference for the required parameters.

I hope you produce many nice results with this release. If you do, we
would like to remind you that we would be happy to get a notice for
placing it on our homepage. :)


Ulf

[Wavepacket-user] Version 5 techdemo1 released

[Ulf L. <ulf...@ke...>]

Hello,

a couple of months ago, I have started a rewrite of WavePacket to fix
various limitations in the current code. For example, right now,
WavePacket supports only one representation (grid + electronic states)
per session, and the Hamiltonian is essentially assumed to be the sum of
kinetic energy operators plus a single potential (set up in one
function) plus a single dipole moment (also set up in one function).

This rewrite has now led to the first public release. It implements
roughly half of the final interface. Right now, you can only set up a
harmonic oscillator and see that the calculated expectation values and
uncertainties are correct, so this release is only of interest to people
who want to get a first glance at The Future.

Requirements are Matlab >= 7.7 (7.6 is buggy and keeps crashing; tech
release 2 might support it, though), and a little patience, because the
better design and improved flexibility increases the computational cost,
especially for small one dimensional problems.


Ulf

[Wavepacket-user] 4.7.1 released

[Ulf L. <ulf...@ke...>]

Hello again,

today is the release date of the next version of WavePacket. This is a
maintenance release that mainly fixes a couple of bugs.

Changes:


* fixed bug #2818039 (possible error with split operator and large time
  steps)
  
	This bug only occured if you use the split operator with permanent
	dipole moments, and if the product of the dipole moment and the time
	step is larger than 2*pi, as can happen for alignment of molecules
	in unscaled units.

* fixed bug when transforming to different grid size (FFT grid)

	In 4.7, a fix for the Fourier-grid was implemented that corrects the
	phases after a DVR->FBR transform. This broke some other code that
	deals with transforming the grid to another one with a different
	number of points.

* expectation values are always calculated for all states

    Implemented due to a user request. This can slightly shift the
	output expectation values because the total potential energy etc. is
	now calculated also for states that are not logged.


Ulf

Re: [Wavepacket-user] problems with wav_interp

[Ulf L. <ulf...@ke...>]

On Mon, Jun 08, 2009 at 10:48:31AM +0200, Monika Leibscher wrote:
> Dear Ulf, dear Burkhard,
> 
> I am trying to run one of your demo-files (Quantum dynamics driven by
> external fields, Electronic excitation of molecules) but with a inital
> wavefunction
> read from a file instead of a initial Gaussian wavefunction.
> 
> However, I am not sure about the exact input for @wav_interp which is
> required in initialize.m.
> 
> Could you help me with a demo file using @wav_interp or a description of
> the required parameters?

Sure. There should be a demo FemtoChem/Interferometry.

The first run (run the rundemo script in FemtoChem.../1) outputs a
relaxed wavepacket to a file, the second run (FemtoChem.../2)
interpolates from the file.

Just reply if you continue having trouble.


Ulf

[Wavepacket-user] problems with wav_interp

[Monika L. <mo...@ch...>]

Dear Ulf, dear Burkhard,

I am trying to run one of your demo-files (Quantum dynamics driven by
external fields, Electronic excitation of molecules) but with a inital
wavefunction
read from a file instead of a initial Gaussian wavefunction.

However, I am not sure about the exact input for @wav_interp which is
required in initialize.m.

Could you help me with a demo file using @wav_interp or a description of
the required parameters?

Thank you very much for your help,

Monika


-- 
Monika Leibscher, PhD            E-mail: mo...@ch...
Freie Universität Berlin
Institut für Chemie und Biochemie
Takustr. 3                                 Tel: (++49 30) 838 55302
D-14195 Berlin                             FAX: (++49 30) 838 54792

[Wavepacket-user] problems with wav_interp

[Monika L. <mo...@ch...>]

Dear Ulf, dear Burkhard,

I am trying to run one of your demo-files (Quantum dynamics driven by
external fields, Electronic excitation of molecules) but with a inital
wavefunction
read from a file instead of a initial Gaussian wavefunction.

However, I am not sure about the exact input for @wav_interp which is
required in initialize.m.

Could you help me with a demo file using @wav_interp or a description of
the required parameters?

Thank you very much for your help,

Monika


-- 
Monika Leibscher, PhD            E-mail: mo...@ch...
Freie Universität Berlin
Institut für Chemie und Biochemie
Takustr. 3                                 Tel: (++49 30) 838 55302
D-14195 Berlin                             FAX: (++49 30) 838 54792

[Wavepacket-user] [Wavepacket-devel] Version 4.7 released

[Ulf L. <ulf...@ke...>]

Hello,

I have just uploaded the packages for version 4.7. I guess it ranks
under "minor feature enhancements". Attached are the changes.


Ulf


Changes:

* added plotting options for only the 1D wavefunction (Cartesian and
  polar plots) and converted some of the demos

* rewrote psi_load; it should have a better interface now

* added a demo for calculating a pump-probe experiment
  (FemtoChem/Interferometry)

* added eigenstates of Morse potential as initial wavefnction

* minor changes
	- setting psi.init.norm (optional) to false causes the initial
	  wave function to be not normalized.
	- wav_load accepts parameter "state" to determine which electronic
	  states to load
	- updates to documentation and demos

* fixes
	- scripts for automated pre-/postprocessing sometimes went amok
	- fixed display bug in Spherical/PendularStates demo=20
	- removed obsoleted parameter from wav_harmonic
	- grid_fft gave incorrect phases when transforming to momentum space

[Wavepacket-user] [Wavepacket-devel] Release 4.6.0

[Ulf L. <ulf...@ke...>]

Hello everyone,

the next release 4.6.0 of WavePacket is out. The changes:

* added solution of multiple coupled TISE's

* added new potentials and dipoles
    - H2O dipole and potentials
	- C9A effective 1D potentials

* added new demos
	- selective bond breakage of HOD (tests interpolation of electric
	  fields)
	- spectrum of C9A molecule with "dark" state (tests coupled TISE's)

* fixed several bugs
	- fixed crash when not supplying optional psi.init.coeffs
	- fixed crash when using an interpolated electric field
	- fixed crash when setting psi.eigen.start to something ~=3D 0
	- fixed crash when using wav_load
	- fixed crash when using psi_load due to obsolete code
	- fixed incorrect evaluation of Fourier Grid Hamiltonian method
	  (should only affect small grids noticeably)



Ulf