You can subscribe to this list here.
2009 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}
(3) 
_{Jul}
(1) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}


2010 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(4) 
_{Jul}

_{Aug}

_{Sep}
(3) 
_{Oct}
(5) 
_{Nov}

_{Dec}

2011 
_{Jan}

_{Feb}

_{Mar}
(2) 
_{Apr}
(1) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(2) 
_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}

_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(1) 
_{Nov}

_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}
(1) 
From: Ulf Lorenz <ulf.lorenz@un...>  20141203 10:59:01

Hi, after about 1.5 years, it is time for a new maintenance release of Wavepacket. This version comes with substantially improved codes for solving bilinear control problems in ODE setting (qm_control), accompanied with two different strategies for dimension reduction: In addition to balanced truncation (qm_balance and qm_truncate) we have also added a code (qm_reduce) for interpolationbased H2model reduction (courtesy by P. Benner, T. Breiten from MPI Magdeburg). There have also been some minor cleanups, fixing and improvements. In parallel, a lot of work has been invested to improve the Wikis so that they are in sync with the Matlab code. Note that the downloads have moved to the corresponding subproject pages. You can download the new version from http://sourceforge.net/projects/matlab.wavepacket.p/files/5.0.0/ This version runs flawlessly for all of our demo examples with Matlab R2013a under Windows7. Should you encounter problems with other Matlab versions and/or other operating systems, please don't hesitate to contact us. Ulf 
From: Ulf Lorenz <ulf@wa...>  20141118 21:28:26

Hello, release 0.1 of the C++ version is finally finished. The two major changes are a rewrite and extension of the initial wave function construction, and a numerical implementation of Redfield dissipation, where you only supply the coupling operator(s) and correlation functions (and a final propagation time and accuracy), and a specialized builder assembles your Redfield operators. Implementing the Redfield dissipation led to a host of other changes as well. The detailed changelog:  new working acceptance test:  SpinBoson problem with Redfield dissipation  started adding demos from old Matlab code  squeezed and shifted state in a harmonic oscillator  cleaned up / improved generation of initial state:  StateBuilder assembles product states, pure density operators from wavefunctions etc.  elementary generators build onedimensional wavefunctions  harmonic oscillator eigenstates  Morse oscillator eigenstates  interpolation from file; setting the 1D wavefunction  New operators:  RedfieldLiouvillian  generalized operators that takes an arbitrary matrix / tensor  timedependent function  added RedfieldBuilder to calculate the effective operators appearing in the RedfieldLiouvillian  New MultiPropagators that can simultaneously propagate several states  added observers that are automatically called every (settable) propagation time steps  added observer that logs norm, energy and some other expectation values  some work to make Wavefunction/DensityManipulators more useful  tests log some of the data; may be put to use for reproducing failures Ulf 
From: Ulf Lorenz <ulf@wa...>  20140413 18:36:32

Hello everyone, I herbey present the next alpha version of the C++ rewrite of Wavepacket. One of the features that we always wanted for the mythical WavePacket 5 was transparent handling of density operators. This was difficult with the current Matlab's code structures, and is now fully supported by the C++ port. There are still many rough edges, starting with the installation, going over the setup of the initial wave packet to the inefficient operator arithmetic, but by changing a few lines of code (~3), you can now convert every wave function propagation into an equivalent density operator propagation, and this feature is meant to stay. For completeness, the changelog:  new working acceptance tests:  Harmonic oscillator with Lindblad dissipation  Density propagation and Wavefunction propagation give same result  added a builder to set up density operators as direct product states  completely reworked how operators work; there is now a primitive that knows what to do with various objects and a highlevel operator that determines the actual action (commute with a density operator or apply to a wavefunction)  added a bunch of new operators:  CommutatorOperator, LindbladLiouvillian as highlevel operators  ConstantOperator, TensorOperator as primitives  added class to simplify transformation of wavefunctions/density operators between the various representation (DVR, FBR, DVR with weights)  added Makefile target and structure for doxygen documentation  slightly simplified the Makefile configuration; fixed a few linker issues  shifted a few files, beautification and simplification of the code/tests etc. Ulf 
From: Ulf Lorenz <ulf@wa...>  20131027 10:03:51

Hi, I just assembled another development version for the C++branch of Wavepacket. It is still far from featurecomplete and a pain to build outside of a Unix environment, though. Download: https://sourceforge.net/projects/wavepacket/files/C%2B%2B%20(experimental)/0.0.2/ Changes:  implemented multidimensional grids  introduced weighted DVR as new representation; this obsoletes the direct exposure of the DVR weights  a couple of new operators: harmonic oscillator, momentum operator, coordinate operator  added addition and summation of operators  added a wave function builder that generates a Gaussian initial state and can build a tensor product of onedimensional wave functions  an acceptance test of a coherent state in a 2D harmonic oscillator The next target will be density operator propagation with a Lindblad dissipative term. Ulf 
From: Ulf Lorenz <ulf@wa...>  20130913 20:04:42

Hi, since it is more fun and faster to have multiple hands available for coding, I would hereby announce that I am also looking for people that want to contribute to the C++ branch of WavePacket. Requirements:  You should know the basics of Wavepacket propagation  You should have some working knowledge of C++ or the necessary dedication to learn it  You should have some working knowledge of objectoriented programming  You should be willing to follow the workflow, which is mostly pairwise discussion/design of the code, and the use of testdriven development If you want to know more about the project, you can start by browsing the wiki at http://sourceforge.net/p/wavepacket/cpp/wiki/Home/ and continue with sending me emails, which I will happily answer. If you are interested, you may also just contact me. Ulf 
From: Ulf Lorenz <ulf@wa...>  20130913 19:58:49

Hi, a while ago, I collected all the things that WavePacket should be able to do, but which require a considerable rewrite, and started working on a C++ toolkit version of WavePacket. This has now reached a stage where it can be published. Version 0.0.1 features welldocumented and thoroughly tested code at the expense of tough requirements of bleeding edge libraries and compilers. It also can only calculate a onedimensional free particle as of now. If you want to have a look at the code so far, you can download it from http://sf.net/projects/wavepacket/files/C%2B%2B (experimental)/0.0.1/ Further information on the how and why of this subproject can be found at http://sourceforge.net/p/wavepacket/cpp/wiki/Home/ Ulf 
From: Burkhard Schmidt <Burkhard.S<chmidt@fu...>  20130307 15:56:38

Dear all, this email is to announce the release of Version 4.9.0 of the WavePacket software (06Mar2013), which is a MatLab program package for simulating quantummechanical wavepacket propagation/dynamics, optionally interacting with electric fields, and with animated graphics. Being highly versatile, it can be used mainly in (photoinduced) physics and chemistry. For further information, see our project at the SF website https://sourceforge.net/projects/wavepacket In addition to the longstanding PDE based solvers for timeindependent (qm_bound) and timedependent (qm_propa) Schroedinger equations, this version now comes with a general code to solve bilinear control problems in ODE setting (qm_control), accompanied with possibility for balanced truncation (qm_balance and qm_truncate). The necessary matrices A,B,N,C,D are provided by Matlab function qm_matrix which can be run for TDSE or LvNE setting for closed or open quantum systems, respectively. In addition, from now on we are using function packages (subdirectories whose name begins with +) such as to organize the source code directory in a convenient and efficient manner. Finally we would also point out the changes associated with the introduction of the Allura GUI used to manage software projects at SF.net. From now on, there will be a Wiki and a Tracker, describing our WavePacket software and coordinating its further development, respectively. Best regards from Berlin/Germany Burkhard  *+*  PD Dr. Burkhard Schmidt  Mailto:burkhard.schmidt@...   Freie Universitaet Berlin  HTTP://page.mi.fuberlin.de/bsch63   Institute for Mathematics  Phone : (+49) 30 / 838  75 369   Arnimallee 6  (+49) 30 / 838  75 367 (secr)   D14195 BerlinDahlem  Fax : (+49) 30 / 838  75 412  *+* 
From: Ulf Lorenz <ulf@wa...>  20121011 19:21:44

On Thu, 11 Oct 2012 09:29:08 +0330 "M.J.Jenabi" <ahjenabi@...> wrote: > In The Name of God, The Compassionate, The Merciful > > Dear Professors Although far from being professor, I would just feel responsible for answering... > I am a PhD student at the Department of Quantum Chemistry of Isfahan > University( IRAN). Excuse me for harassment No problem, that is what this mailing list is for. > I have two questions: > > 1. Is this program used to transfer the electron wave packet > Or just for the nuclear wave packet Typically, you would calculate the nuclear wave packet, but if you have a potential available and use some singleelectron approximation, then you should in principle also be able to calculate electronic wavepackets. It is not useful for electronic structure calculations (multiple, indistinguishable particles), though. > 2. can be performed a multidimensional calculations Yes. You have to define grids in multiple dimensions (see e.g., the harmonic oscillator demo in 2D), and that is it. Ulf 
From: M.J.Jenabi <ahjenabi@gm...>  20121011 05:59:15

In The Name of God, The Compassionate, The Merciful Dear Professors I am a PhD student at the Department of Quantum Chemistry of Isfahan University( IRAN). Excuse me for harassment I have two questions: 1. Is this program used to transfer the electron wave packet Or just for the nuclear wave packet 2. can be performed a multidimensional calculations Thank you for your considerations. Best regards Mohammad Jafar Jenabi 
From: Ulf Lorenz <ulf@wa...>  20120418 18:26:02

Hi, it took a bit longer than expected to get the next version ready, but we finally put it together. I would not repeat the full changelog, but only the brief highlights. For an exhaustive list of all changes, see http://sourceforge.net/apps/mediawiki/wavepacket/index.php?title=WavePacket4.ChangeLog Changes: * modified the code flow; instead of calling qm_propa, you now call the sequence qm_setup(); initialize(); qm_propa(); qm_cleanup(). This should hugely simplify scripting in some cases. * modified psi_load() to allow caching when loading wave functions from multiple calculations simultaneously * started work on Optimal Control Theory (RWA, propagation backwards in time) * implemented propagation in an abstract ket basis and of density operators [experimental] * updated documentation (now on the wiki) * a number of bugfixes Compatibility issues: * when starting a calculation, you now have to call a few more functions * psi_load() has a slightly different syntax for retrieving the wave function. Ulf 
From: Ulf Lorenz <ulf@wa...>  20120209 15:54:11

For the record: answered by phone call. Ulf 
From: Thomas Brumme <thomas.brumme@na...>  20120207 12:43:30

Hi, first of all, thank you for this awesome piece of code! I'm actually trying to use WavePacket to simulated the wavepacket propagation through a 3d potential I get from a plain DFT calculation. After a few problems with the interpolation (I essentially had to change the interpolation method from "interp3" to "griddata3", using the nearest neighbor method) it now seems to work. However, there is one problem I encountered during visualizing the result in the "reduced" plot form. I start my calculations with a momentum of [0 0 2] (particle moving in positive zdirection), but the plots always show gaussian packets with the center near a momentum of [0 0 2]. But this can only be a problem of the visualization since the code writes correctly [0 0 2] in the console... Furthermore, another strange thing I had... I used periodic boundary conditions and a test potential. The cell has 50x50x50 points. Depending on the conversion factor I can make any unit cell size out of this (cubic of course). And I changed the conversion factor. However, for each different value of unit cell size, the wavepacket spreads very rapidly and after a few time steps the center of the packet is in the center of the cell and it only gets broadened. I should use a correlated wavepacket in this case to get more reasonable results, or? One last question: Is there a easy way to print out the gradient of the potential at the center of the wavepacket to get the electric field at this point? Can you give me maybe at least a hint in which part of the code I would have to add the corresponding matlab expression? (i.e. in which variable is the center of the wavepacket stored and where is it calculated) Thank you in advance Thomas Brumme  Dipl.Nat. Thomas Brumme Institute for Materials Science and Max Bergmann Center of Biomaterials Dresden University of Technology Hallwachsstr. 3 01069 Dresden, Germany Tel: +49 (0)351 463 31408 email: Thomas.Brumme@... www: http://nano.tudresden.de/~tbrumme/ 
From: <ulf.lorenz@de...>  20110513 16:00:16

Hello everyone, first, I want to announce that the reference for the settable parameters has been moved to the wiki and can be found under http://sourceforge.net/apps/mediawiki/wavepacket/index.php?title=WavePacket4.Reference.Main This is also the version that we will continue to maintain. Then, we also plan on migrating the more useful parts of the manual to the wiki and to add a tutorial in the nearer future. Now the question is: What do you suggest to have in the manual or tutorial? There are probably a few things that you came across that were not obvious, or where you would have appreciated (or maybe still appreciate) a better documentation. What are they? As a guideline, my current schedule for the manual is to have some documentation on:  the basic layout (code flow, what you have to do to run a calculation)  how interpolation works  how the grids work  how truncation works  how electric fields work  saving and loading For the tutorial, I have not thought too much yet. It should probably build up roughly like this: 1. Getting started (1D harmonic oscillator or so) 2. multidimensional grids 3. multiple electronic states, diabatic/adiabatic etc. 4. Adding Electric fields 5. Saving/loading; simple scripting 6. Writing an own potential/dipole function. Ulf 
From: Ulf Lorenz <ulf.lorenz@de...>  20110404 12:54:49

On Fri, 20110325 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 timedependent 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! For the record: The culprit was a custom modification in the file psi_save.m. Ulf 
From: Ulf Lorenz <ulf.lorenz@de...>  20110328 08:39:37

On Fri, 20110325 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 timedependent 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 
From: Jijun Xu <jijunxu@gm...>  20110325 13:06:09

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 timedependent 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: Lorenz, Ulf <ulf.lorenz@de...>  20101024 18:55:56

One correction , and one addon: > On Wed, 20101020 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 
From: Ulf Lorenz <ulf.lorenz@de...>  20101021 09:26:06

On Wed, 20101020 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 strongfield 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 
From: wanglei365x<wanglei365x@16...>  20101020 09:38:34

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) 20101020 wanglei365x 
From: Ulf Lorenz <ulf.lorenz@de...>  20101020 07:57:00

On Wed, 20101020 at 10:35 +0800, wanglei365x wrote: > hello, > i am one of the wavepacketusers, 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 = maxmin is. In this case, hamilt.truncate.{minmax} 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.{minmax}) 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 
From: wanglei365x<wanglei365x@16...>  20101020 02:36:09

hello, i am one of the wavepacketusers, 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. 20101020 wanglei365x 
From: Ulf Lorenz <ulf.lorenz@ke...>  20100929 10:59:16

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 
From: Jakob Petersen <petersen.jakob@gm...>  20100923 13:12:57

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 petersen.jakob@...  (+45) 31 24 79 73 
From: Ulf Lorenz <ulf.lorenz@ke...>  20100916 17:29:41

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 
From: Ulf Lorenz <ulf.lorenz@ke...>  20100618 10:02:43

On Wed, Jun 16, 2010 at 12:36:51PM +0200, Ulf Lorenz wrote: > On Wed, Jun 16, 2010 at 11:36:16AM +0200, belzst@... wrote: > > Another point is the possibility of creating movies in a noninteractive > > 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 noninteractive 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 