[Octopus-devel] octopus_cmplx is gone (was: Re: [Octopus-notify] svn commit: r2088 - in trunk: . build doc src testsuite/finite_systems_2d testsuite/finite_systems_3d by micael)

[Heiko Appel]

Mi Micael,

very good!!! That was actually a long standing item on the cleanup 
agenda :). Well done.

The TS macro disappeared basically with my MPI cleanup yesterday.
(at least it is not used anymore). 

We will now also need to update the nightly builds since they still
assume that a --enable-complex exists. I'll take care of that 
later today (Axel is around today and we will continue with the GUI
bits). Also I'll try to have a look at the implications for the MPI 
executable.

Ignoring the value of WaveFunctionsType is not a good idea, I think.
We should always stop the code if something is fishy. Later on we
can start repairing the logics. That was at least the philosophy
Florian and I tried to follow when had parallel and (broken) non-parallel
bits around ...

best wishes,

	Heiko


On Wed, May 17, 2006 at 04:55:32PM +0100, octopus-notify at tddft.org wrote:
>       Author: micael
>         Date: Wed May 17 16:55:28 2006
> New Revision: 2088
>    Changeset: http://www.tddft.org/trac/octopus/changeset/2088
> 
> Added:
>    trunk/src/casida_inc.F90
>    trunk/src/eigen_inc.F90
>    trunk/src/lcao_inc.F90
>    trunk/src/unocc_inc.F90
> Modified:
>    trunk/INSTALL
>    trunk/build/var2xml.py
>    trunk/configure.ac
>    trunk/doc/octopus.info
>    trunk/doc/octopus.texi
>    trunk/src/Makefile.am
>    trunk/src/casida.F90
>    trunk/src/crystal.F90
>    trunk/src/eigen.F90
>    trunk/src/eigen_cg.F90
>    trunk/src/eigen_evolution.F90
>    trunk/src/eigen_plan.F90
>    trunk/src/em_resp.F90
>    trunk/src/em_resp_inc.F90
>    trunk/src/epot.F90
>    trunk/src/epot_inc.F90
>    trunk/src/geom_opt.F90
>    trunk/src/global.h
>    trunk/src/gs.F90
>    trunk/src/h.F90
>    trunk/src/h_inc.F90
>    trunk/src/h_so.F90
>    trunk/src/lcao.F90
>    trunk/src/linear_response.F90
>    trunk/src/linear_response_inc.F90
>    trunk/src/opt_control.F90
>    trunk/src/phonons.F90
>    trunk/src/restart.F90
>    trunk/src/restart_inc.F90
>    trunk/src/scf.F90
>    trunk/src/states.F90
>    trunk/src/states_inc.F90
>    trunk/src/static_pol.F90
>    trunk/src/systm.F90
>    trunk/src/td.F90
>    trunk/src/td_calc.F90
>    trunk/src/td_rti.F90
>    trunk/src/td_write.F90
>    trunk/src/unocc.F90
>    trunk/src/v_ks.F90
>    trunk/src/v_ks_inc.F90
>    trunk/testsuite/finite_systems_2d/01-quadratic_box.01-ground_state.inp
>    trunk/testsuite/finite_systems_2d/01-quadratic_box.02-hartree.inp
>    trunk/testsuite/finite_systems_2d/01-quadratic_box.test
>    trunk/testsuite/finite_systems_2d/02-fock-darwin.01-ground_state.inp
>    trunk/testsuite/finite_systems_2d/02-fock-darwin.test
>    trunk/testsuite/finite_systems_3d/07-spin_orbit_coupling.01-ground_state.inp
>    trunk/testsuite/finite_systems_3d/07-spin_orbit_coupling.test
>    trunk/testsuite/finite_systems_3d/09-spinors.01-ground_state.inp
>    trunk/testsuite/finite_systems_3d/09-spinors.test
>    trunk/testsuite/periodic_systems_1d/01-free_electrons.01-ground_state.inp
>    trunk/testsuite/periodic_systems_1d/01-free_electrons.test
>    trunk/testsuite/periodic_systems_1d/02-cosine_potential.01-ground_state.inp
>    trunk/testsuite/periodic_systems_1d/02-cosine_potential.test
>    trunk/testsuite/periodic_systems_1d/03-sodium_chain.01-ground_state.inp
>    trunk/testsuite/periodic_systems_1d/03-sodium_chain.test
> 
> Log:
>  octopus_cmplx is gone :)
> 
>  This obviously implied a lot of changes:
>    - there is now a new variable called WaveFunctionsType to decide if 
>      one wants to use complex or real wavefunctions.
>    - some macros like R_TYPE and X() are now only accessible in the *_inc.F90 files.
>    - I had to move some routines from and to the *_inc.F90 files.
> 
>  The code passes all the serial tests (I update the complex tests), but I guess
> somethings probably got broken.
>  I did not check the mpi executable. I think there might be some problem with the TS()
> macro. Can someone check this?
>  Another issue is the places in the code were the wave-functions have to be real/complex.
> For the cases I knew of, the code will either stop if the value of WaveFunctionsType in
> the input file is not correct or ignore it (maybe this is not very good, but I did not
> know how to do it otherwise).
> 
>  During this changes I found several inconsistencies in the use of real/complex
> variables and related macros. For example, in the em_resp module, R_CONJ() was used
> with some variables that were always complex... In other places real values were 
> assigned to complex variables, etc.
> 
>  I guess the code will need some testing and cleaning during the next couple of weeks.
> 
> 
> 
> _______________________________________________
> Octopus-notify mailing list
> Octopus-notify at tddft.org
> http://www.tddft.org/mailman/listinfo/octopus-notify
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.tddft.org/pipermail/octopus-devel/attachments/20060517/c5c94673/attachment.bin