cppqed-support — Bugs, questions, feature requests, etc.

[Cppqed-support] clang compiler support

[Andras V. <and...@ui...>]

Hi,

After some time, today I tried again to compile the framework with the
clang compiler. What I experience is that clang ...

* ... can mostly compile the BlitzCVS_compatibility branch, except for
an error inside FLENS which used to be there at the time of my earlier
tries as well. Therefore, I patched FLENS, so that clang compiles most
of this branch, except for a few scripts.

* ... cannot compile main-branch C++QED because of some error it finds
inside blitz++. So, what I did was to patch Blitz as well.

As last time, clang again noticed some funny little mistakes that gcc
does accept. These mistakes have been corrected, I will push the
update tomorrow.

Best regards,
András

Re: [Cppqed-support] Ubuntu packages

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

Dear András,

I wasn't aware of the different version provided in the universe repository, 
and the naming and versioning is most unfortunate: libboost-serialization-dev 
has version 1.48.0.2 but indeed is a meta-package for version 1.46. 

As far as I know the boost libraries are not binary compatible across 
versions. 

This problem occurs only if the user has explicitly installed the universe 
boost *headers*, if it is only the universe boost libraries everything should 
be fine. And it also happens with standard Ubuntu packages: you should see the 
same conflict when you try to install e.g. libftdipp-dev.

We can do one of the following to work around the problem:

* Unconditionally link against the universe version of boost. Everyone has to 
enable the universe repository to install our package. Apart from that, 
another downside to this approach is that some dev packages in Ubuntu depend 
on the default boost. If one of these is installed there will be a clash 
(similar to the one you experienced only the other way around) when trying to 
install c++qed. Only one version of the boost-dev packages is allowed.

* Provide two separate packages, the default package links against the default 
boost version, and a specialized package links against the universe boost 
version on each series. This way users who don't care which version of boost 
to use (probably most) can just install the default package without worrying 
too much.

* You install your boost version from source and not via apt-get ;)

What do you think?

In both cases we have to use a different build branch for each series, as the 
package names of boost in universe differ across the series. This is not too 
bad, though.

Best regards
Raimar


On Monday 27 August 2012 14:48:40 Andras Vukics wrote:
> Dear Raimar,
> 
> On Precise I have the problem that I had
> libboost-serialization1.48-dev, but libc++qed-dev is looking for
> libboost-serialization-dev, which is I think a meta-package for the
> 1.46 version.
> 
> Can you do something about this?
> 
> Cheers,
> András
> 
> On Mon, Aug 27, 2012 at 1:04 PM, Andras Vukics <and...@ui...> 
wrote:
> > Dear Raimar,
> > 
> >> it is possible to add FLENS, but I would have to create a FLENS package
> >> because at the moment there is none in Ubuntu. A conditional FLENS
> >> dependency is only possible if we have two separate packages, one with
> >> and one without FLENS (e.g. libc++qed and libc++qed_flens). But the
> >> FLENS dependency doesn't hurt much even for people who don't use it.
> > 
> > Right, it should not hurt much, so it could be added as a dependency
> > unconditionally.
> > 
> >> I would suggest to rename "Installation" to "Installation from source"
> >> and add a section "Installation from packages".
> > 
> > Fine.
> > 
> >> By publishing on the index page, do you mean to provide the .deb files as
> >> downloads or to give instructions how to install from the repository?
> > 
> > Perhaps just a link into the Download section of the index page either
> > to the section "Installation from packages" or directly to the
> > launchpad page.
> > 
> > Best regards,
> > András		

Re: [Cppqed-support] Ubuntu packages

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

Dear András,

it is possible to add FLENS, but I would have to create a FLENS package 
because at the moment there is none in Ubuntu. A conditional FLENS dependency 
is only possible if we have two separate packages, one with and one without 
FLENS (e.g. libc++qed and libc++qed_flens). But the FLENS dependency doesn't 
hurt much even for people who don't use it.

At the moment the packages are created directly from my branch cppqed/raimar 
because of some recent changes to cmake, but later we can switch this to 
master. The way it works: on launchpad there is an exact copy of the 
development branch and an additional branch which contains the information how 
to build the packages (checkout lp:~raimar-sandner/+junk/cppqed-debian-build 
if you want to have a look). These two branches are then automatically merged 
and source packages for the various distributions and architectures are 
created and then built on the launchpad build farm.

I would suggest to rename "Installation" to "Installation from source" and add 
a section "Installation from packages". I plan to write a Gentoo ebuild and 
Sebastian could contribute Arch-Linux packages. 

By publishing on the index page, do you mean to provide the .deb files as 
downloads or to give instructions how to install from the repository?

Best regards
Raimar

On Monday 27 August 2012 10:50:59 Andras Vukics wrote:
> Dear Raimar,
> 
> This looks great. Did you create it simply from the main branch? Do
> you think it would be possible to add FLENS as a dependency (perhaps
> conditionally somehow)?
> 
> It would be nice if you could document this a little bit, perhaps we
> should publish the packages already on the index page.
> 
> Let's skype early afternoon.
> 
> Bests,
> András
> 
> 
> 
> 
> On Mon, Aug 27, 2012 at 10:20 AM, Raimar Sandner
> 
> <rai...@ui...> wrote:
> > Dear András,
> > 
> > I have prepared Ubuntu packages for C++QED.
> > 
> > https://launchpad.net/~raimar-sandner/+archive/cppqed
> > 
> > The packages can be installed with
> > 
> > sudo add-apt-repository ppa:raimar-sandner/cppqed
> > sudo apt-get update
> > sudo apt-get install c++qed-scripts libc++qed-dev
> > 
> > In addition to blitz-0.10 there are three packages in the repository, each
> > compiled for 32 and 64 bit architecture and for the Ubuntu series Quantal,
> > Precise and Oneiric (other series can be added):
> > 
> > * libc++qed: the libraries libC++QED.so, libel.so and libutils.so
> > 
> > * libc++qed-dev: the header files and an example cmake project
> > /usr/share/doc/libc++qed-dev/examples with all the script source files and
> > an CMakeLists.txt which demonstrates how to compile scripts. A Readme.txt
> > in the directory explains this.
> > 
> > * c++qed-scripts: the scripts as executables, ready to run.
> > 
> > 
> > Distributing new snapshot packages is as easy as pushing to a special
> > bazaar repository on launchpad and requesting a build on the web
> > interface.
> > 
> > Can we skype later today?
> > 
> > Best regards
> > Raimar
> > 
> > --------------------------------------------------------------------------
> > ---- Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Cppqed-support mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppqed-support

Re: [Cppqed-support] Ubuntu packages

[Andras V. <and...@ui...>]

Dear Raimar,

This looks great. Did you create it simply from the main branch? Do
you think it would be possible to add FLENS as a dependency (perhaps
conditionally somehow)?

It would be nice if you could document this a little bit, perhaps we
should publish the packages already on the index page.

Let's skype early afternoon.

Bests,
András




On Mon, Aug 27, 2012 at 10:20 AM, Raimar Sandner
<rai...@ui...> wrote:
> Dear András,
>
> I have prepared Ubuntu packages for C++QED.
>
> https://launchpad.net/~raimar-sandner/+archive/cppqed
>
> The packages can be installed with
>
> sudo add-apt-repository ppa:raimar-sandner/cppqed
> sudo apt-get update
> sudo apt-get install c++qed-scripts libc++qed-dev
>
> In addition to blitz-0.10 there are three packages in the repository, each
> compiled for 32 and 64 bit architecture and for the Ubuntu series Quantal,
> Precise and Oneiric (other series can be added):
>
> * libc++qed: the libraries libC++QED.so, libel.so and libutils.so
>
> * libc++qed-dev: the header files and an example cmake project
> /usr/share/doc/libc++qed-dev/examples with all the script source files and an
> CMakeLists.txt which demonstrates how to compile scripts. A Readme.txt in the
> directory explains this.
>
> * c++qed-scripts: the scripts as executables, ready to run.
>
>
> Distributing new snapshot packages is as easy as pushing to a special bazaar
> repository on launchpad and requesting a build on the web interface.
>
> Can we skype later today?
>
> Best regards
> Raimar
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support

[Cppqed-support] Ubuntu packages

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

Dear András,

I have prepared Ubuntu packages for C++QED.

https://launchpad.net/~raimar-sandner/+archive/cppqed

The packages can be installed with

sudo add-apt-repository ppa:raimar-sandner/cppqed
sudo apt-get update
sudo apt-get install c++qed-scripts libc++qed-dev

In addition to blitz-0.10 there are three packages in the repository, each 
compiled for 32 and 64 bit architecture and for the Ubuntu series Quantal, 
Precise and Oneiric (other series can be added):

* libc++qed: the libraries libC++QED.so, libel.so and libutils.so

* libc++qed-dev: the header files and an example cmake project 
/usr/share/doc/libc++qed-dev/examples with all the script source files and an 
CMakeLists.txt which demonstrates how to compile scripts. A Readme.txt in the 
directory explains this.

* c++qed-scripts: the scripts as executables, ready to run.


Distributing new snapshot packages is as easy as pushing to a special bazaar 
repository on launchpad and requesting a build on the web interface.

Can we skype later today?

Best regards
Raimar

[Cppqed-support] BoostIntegration

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

Hi!

I have pushed raimar/BoostIntegrationCmake.

Best regards
Raimar

Re: [Cppqed-support] new tcc include scheme + compilation issues + Composite compile-time consistency

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

Dear András,

thanks for merging and for the explanation of the coompile-time checks.

I will bring the boost-integration branch into shape with the new cmake build 
system.

Best regards
Raimar

On Friday 17 August 2012 10:40:24 Andras Vukics wrote:
> Dear Raimar,
> 
> Thanks for your work on this.
> I merged into the master branch and updated the documentation.
> 
> I also agree with what you did for the Mac OS support. I also merged
> into BlitzCVS_compatibility from raimar/BlitzCVS_cmake.
> 
> As to the consistency checks for Composite at compile time, they come
> on three levels:
> 
> * Composite itself only checks whether all the quantum numbers are
> addressed by an Act. So this is e.g. not allowed:
> composite::result_of::Make<Act<0,1>,Act<0,2>,Act<0,3>,Act<3,2,5,1> >::type
> because 4 is not addressed and hence the Composite object has no way
> to figure out what kind of Free object is there.
> 
> * The instantiated slice iterators do some further checks for each Act
> individually:
>   - RANK must be greater than or equal to the arity of Act
>   - Act must not "contain" duplicated "elements" (Act<3,2,3,1> not allowed)
>   - each element in Act must be smaller than RANK
> 
> * Finally, tmptools::Vector checks for the non-negativity of each
> element (as it is supposed to be a non-negative compile-time vector)
> 
> This is followed by a check at runtime, when the actual elements
> become available, whether the legs of the Act objects are consistent
> among each other. Cf. composite::FillFrees::Inner::operator() .
> 
> Best regards,
> András
> 
> 
> 
> 
> 
> On Thu, Aug 16, 2012 at 3:46 PM, Raimar Sandner
> 
> <rai...@ui...> wrote:
> > I updated all the include guards to make them consistent
> > (raimar/tccStaging) and documented the conventions used
> > (raimar/Documentation). The rules are:
> > 
> > filename with path relative to project dir -> uppercase -> replace '.' and
> > '/' with '_' -> append _INCLUDED
> > 
> > With this convention in place fixing include guards can be easily
> > automated in the future by parsing for lines which contain _INCLUDED and
> > rewrite them.
> > 
> > Actually, this does the job:
> > 
> > for f in $(find * -name *.h -o -name *.tcc);\
> > do \
> > 
> >   perl -pi -e "s[(\S*_INCLUDED)]{my
> >   \$newguard=uc(qq(${f}_INCLUDED));\$newguard=~ s|[./]|_|g;
> >   qq(\$newguard)}e" $f; \> 
> > done
> > 
> > This will scan every .h and .tcc file and replace any include guard which
> > contains _INCLUDED by one that conforms to the rules above.> 
> > On Tuesday 14 August 2012 11:38:26 Raimar Sandner wrote:
> >> Dear András,
> >> 
> >> I removed MCWF.h and added explicit template instantiations for
> >> BinarySystem. The result is in raimar/tccStaging, and it compiles in
> >> release mode again.
> >> 
> >> Best regards
> >> Raimar
> >> 
> >> On Monday 13 August 2012 11:04:59 Andras Vukics wrote:
> >> > Dear Raimar,
> >> > 
> >> > To me, everything you did here seems fine, I have only one small
> >> > question:
> >> > * Why is there a separate MCWF.h, and if there is, why does
> >> > Evolution.h not include it ? EvolutionHigh.h used to pull in
> >> > everything needed to evolve on quantumtrajectories.
> >> > 
> >> > Please check out the branch tccStaging where I have updated
> >> > utils/testsuite and corrected a few small problems. The testsuite can
> >> > be run simply with
> >> > bjam (release)
> >> > in the utils/testsuite folder.
> >> > 
> >> > I made a small test, and compilation dependencies have indeed
> >> > decreased with this scheme:
> >> > 
> >> > quantumdata/impl/StateVector.tcc: 51 targets depends on it (used to be
> >> > 58 targets)
> >> > elements/frees/impl/Mode.tcc: 32 targets (58 targets)
> >> > 
> >> > utils/include/impl/Evolved.tcc: 50 targets (60 targets)
> >> > utils/include/impl/BlitzArraySliceIterator.tcc: 50 targets (54 targets)
> >> > 
> >> > Thanks and best regards,
> >> > András
> >> > 
> >> > 
> >> > 
> >> > On Sat, Aug 11, 2012 at 2:03 AM, Raimar Sandner
> >> > 
> >> > <rai...@ui...> wrote:
> >> > > Dear András,
> >> > > 
> >> > > I have pushed raimar/tcc_new (and removed raimar/tcc). Tcc_new is
> >> > > already
> >> > > branched from the latest r229 of master so that you don't need to
> >> > > merge
> >> > > with the binary and composite changesets again.
> >> > > 
> >> > > I tried to stick to what we have discussed recently and also updated
> >> > > the
> >> > > code organization rationales accordingly (raimar/Documentation).
> >> > > 
> >> > > Please note that I have also converted the pair
> >> > > BlitzArraySlieIterator.h/tcc to the new style by defining the macros
> >> > > in
> >> > > a
> >> > > separate file which is included in both headers. Now the tcc scheme
> >> > > is
> >> > > consistent across the framework, but if you don't like this approach
> >> > > just
> >> > > leave out the last commit when you merge.
> >> > > 
> >> > > Furthermore I have added LazyDensityOperator.tcc, and converted some
> >> > > of
> >> > > the
> >> > > frees headers to Free_.h so that Free.h can bundle Free_.h (or
> >> > > impl/Free.tcc if present) together with ParsFree.h. However, I have
> >> > > not
> >> > > changed the interaction header files in the same way yet. Currently
> >> > > these
> >> > > are not used anywhere in the framework and Pars... headers are just
> >> > > included in the corresponding interaction header file, so script
> >> > > users
> >> > > have only to include this one header file anyway.
> >> > > 
> >> > > Best regards
> >> > > Raimar
> >> > > 
> >> > > 
> >> > > PS: probably the testsuites are pretty much broken right now because
> >> > > of
> >> > > all
> >> > > these changes, but I could not start them to check. How do I run the
> >> > > tests
> >> > > with bjam again?
> >> > > 
> >> > > ---------------------------------------------------------------------
> >> > > ---
> >> > > --
> >> > > ---- Live Security Virtual Conference
> >> > > Exclusive live event will cover all the ways today's security and
> >> > > threat landscape has changed and how IT managers can respond.
> >> > > Discussions
> >> > > will include endpoint security, mobile security and the latest in
> >> > > malware
> >> > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> > > _______________________________________________
> >> > > Cppqed-support mailing list
> >> > > Cpp...@li...
> >> > > https://lists.sourceforge.net/lists/listinfo/cppqed-support
> > 
> > --------------------------------------------------------------------------
> > ---- Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Cppqed-support mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppqed-support

[Cppqed-support] new tcc include scheme + compilation issues + Composite compile-time consistency

[Andras V. <and...@ui...>]

Dear Raimar,

Thanks for your work on this.
I merged into the master branch and updated the documentation.

I also agree with what you did for the Mac OS support. I also merged
into BlitzCVS_compatibility from raimar/BlitzCVS_cmake.

As to the consistency checks for Composite at compile time, they come
on three levels:

* Composite itself only checks whether all the quantum numbers are
addressed by an Act. So this is e.g. not allowed:
composite::result_of::Make<Act<0,1>,Act<0,2>,Act<0,3>,Act<3,2,5,1> >::type
because 4 is not addressed and hence the Composite object has no way
to figure out what kind of Free object is there.

* The instantiated slice iterators do some further checks for each Act
individually:
  - RANK must be greater than or equal to the arity of Act
  - Act must not "contain" duplicated "elements" (Act<3,2,3,1> not allowed)
  - each element in Act must be smaller than RANK

* Finally, tmptools::Vector checks for the non-negativity of each
element (as it is supposed to be a non-negative compile-time vector)

This is followed by a check at runtime, when the actual elements
become available, whether the legs of the Act objects are consistent
among each other. Cf. composite::FillFrees::Inner::operator() .

Best regards,
András





On Thu, Aug 16, 2012 at 3:46 PM, Raimar Sandner
<rai...@ui...> wrote:
> I updated all the include guards to make them consistent (raimar/tccStaging) and documented the conventions used (raimar/Documentation).
> The rules are:
>
> filename with path relative to project dir -> uppercase -> replace '.' and '/' with '_' -> append _INCLUDED
>
> With this convention in place fixing include guards can be easily automated in the future by parsing for lines which contain _INCLUDED and rewrite them.
>
> Actually, this does the job:
>
> for f in $(find * -name *.h -o -name *.tcc);\
> do \
>   perl -pi -e "s[(\S*_INCLUDED)]{my \$newguard=uc(qq(${f}_INCLUDED));\$newguard=~ s|[./]|_|g; qq(\$newguard)}e" $f; \
> done
>
> This will scan every .h and .tcc file and replace any include guard which contains _INCLUDED by one that conforms to the rules above.
>
>
>
> On Tuesday 14 August 2012 11:38:26 Raimar Sandner wrote:
>> Dear András,
>>
>> I removed MCWF.h and added explicit template instantiations for
>> BinarySystem. The result is in raimar/tccStaging, and it compiles in
>> release mode again.
>>
>> Best regards
>> Raimar
>>
>> On Monday 13 August 2012 11:04:59 Andras Vukics wrote:
>> > Dear Raimar,
>> >
>> > To me, everything you did here seems fine, I have only one small question:
>> > * Why is there a separate MCWF.h, and if there is, why does
>> > Evolution.h not include it ? EvolutionHigh.h used to pull in
>> > everything needed to evolve on quantumtrajectories.
>> >
>> > Please check out the branch tccStaging where I have updated
>> > utils/testsuite and corrected a few small problems. The testsuite can
>> > be run simply with
>> > bjam (release)
>> > in the utils/testsuite folder.
>> >
>> > I made a small test, and compilation dependencies have indeed
>> > decreased with this scheme:
>> >
>> > quantumdata/impl/StateVector.tcc: 51 targets depends on it (used to be
>> > 58 targets)
>> > elements/frees/impl/Mode.tcc: 32 targets (58 targets)
>> >
>> > utils/include/impl/Evolved.tcc: 50 targets (60 targets)
>> > utils/include/impl/BlitzArraySliceIterator.tcc: 50 targets (54 targets)
>> >
>> > Thanks and best regards,
>> > András
>> >
>> >
>> >
>> > On Sat, Aug 11, 2012 at 2:03 AM, Raimar Sandner
>> >
>> > <rai...@ui...> wrote:
>> > > Dear András,
>> > >
>> > > I have pushed raimar/tcc_new (and removed raimar/tcc). Tcc_new is
>> > > already
>> > > branched from the latest r229 of master so that you don't need to merge
>> > > with the binary and composite changesets again.
>> > >
>> > > I tried to stick to what we have discussed recently and also updated the
>> > > code organization rationales accordingly (raimar/Documentation).
>> > >
>> > > Please note that I have also converted the pair
>> > > BlitzArraySlieIterator.h/tcc to the new style by defining the macros in
>> > > a
>> > > separate file which is included in both headers. Now the tcc scheme is
>> > > consistent across the framework, but if you don't like this approach
>> > > just
>> > > leave out the last commit when you merge.
>> > >
>> > > Furthermore I have added LazyDensityOperator.tcc, and converted some of
>> > > the
>> > > frees headers to Free_.h so that Free.h can bundle Free_.h (or
>> > > impl/Free.tcc if present) together with ParsFree.h. However, I have not
>> > > changed the interaction header files in the same way yet. Currently
>> > > these
>> > > are not used anywhere in the framework and Pars... headers are just
>> > > included in the corresponding interaction header file, so script users
>> > > have only to include this one header file anyway.
>> > >
>> > > Best regards
>> > > Raimar
>> > >
>> > >
>> > > PS: probably the testsuites are pretty much broken right now because of
>> > > all
>> > > these changes, but I could not start them to check. How do I run the
>> > > tests
>> > > with bjam again?
>> > >
>> > > ------------------------------------------------------------------------
>> > > --
>> > > ---- Live Security Virtual Conference
>> > > Exclusive live event will cover all the ways today's security and
>> > > threat landscape has changed and how IT managers can respond.
>> > > Discussions
>> > > will include endpoint security, mobile security and the latest in
>> > > malware
>> > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> > > _______________________________________________
>> > > Cppqed-support mailing list
>> > > Cpp...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/cppqed-support
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support

Re: [Cppqed-support] new tcc include scheme

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

I updated all the include guards to make them consistent (raimar/tccStaging) and documented the conventions used (raimar/Documentation).
The rules are:

filename with path relative to project dir -> uppercase -> replace '.' and '/' with '_' -> append _INCLUDED
  
With this convention in place fixing include guards can be easily automated in the future by parsing for lines which contain _INCLUDED and rewrite them.

Actually, this does the job:

for f in $(find * -name *.h -o -name *.tcc);\
do \
  perl -pi -e "s[(\S*_INCLUDED)]{my \$newguard=uc(qq(${f}_INCLUDED));\$newguard=~ s|[./]|_|g; qq(\$newguard)}e" $f; \
done

This will scan every .h and .tcc file and replace any include guard which contains _INCLUDED by one that conforms to the rules above.



On Tuesday 14 August 2012 11:38:26 Raimar Sandner wrote:
> Dear András,
> 
> I removed MCWF.h and added explicit template instantiations for
> BinarySystem. The result is in raimar/tccStaging, and it compiles in
> release mode again.
> 
> Best regards
> Raimar
> 
> On Monday 13 August 2012 11:04:59 Andras Vukics wrote:
> > Dear Raimar,
> > 
> > To me, everything you did here seems fine, I have only one small question:
> > * Why is there a separate MCWF.h, and if there is, why does
> > Evolution.h not include it ? EvolutionHigh.h used to pull in
> > everything needed to evolve on quantumtrajectories.
> > 
> > Please check out the branch tccStaging where I have updated
> > utils/testsuite and corrected a few small problems. The testsuite can
> > be run simply with
> > bjam (release)
> > in the utils/testsuite folder.
> > 
> > I made a small test, and compilation dependencies have indeed
> > decreased with this scheme:
> > 
> > quantumdata/impl/StateVector.tcc: 51 targets depends on it (used to be
> > 58 targets)
> > elements/frees/impl/Mode.tcc: 32 targets (58 targets)
> > 
> > utils/include/impl/Evolved.tcc: 50 targets (60 targets)
> > utils/include/impl/BlitzArraySliceIterator.tcc: 50 targets (54 targets)
> > 
> > Thanks and best regards,
> > András
> > 
> > 
> > 
> > On Sat, Aug 11, 2012 at 2:03 AM, Raimar Sandner
> > 
> > <rai...@ui...> wrote:
> > > Dear András,
> > > 
> > > I have pushed raimar/tcc_new (and removed raimar/tcc). Tcc_new is
> > > already
> > > branched from the latest r229 of master so that you don't need to merge
> > > with the binary and composite changesets again.
> > > 
> > > I tried to stick to what we have discussed recently and also updated the
> > > code organization rationales accordingly (raimar/Documentation).
> > > 
> > > Please note that I have also converted the pair
> > > BlitzArraySlieIterator.h/tcc to the new style by defining the macros in
> > > a
> > > separate file which is included in both headers. Now the tcc scheme is
> > > consistent across the framework, but if you don't like this approach
> > > just
> > > leave out the last commit when you merge.
> > > 
> > > Furthermore I have added LazyDensityOperator.tcc, and converted some of
> > > the
> > > frees headers to Free_.h so that Free.h can bundle Free_.h (or
> > > impl/Free.tcc if present) together with ParsFree.h. However, I have not
> > > changed the interaction header files in the same way yet. Currently
> > > these
> > > are not used anywhere in the framework and Pars... headers are just
> > > included in the corresponding interaction header file, so script users
> > > have only to include this one header file anyway.
> > > 
> > > Best regards
> > > Raimar
> > > 
> > > 
> > > PS: probably the testsuites are pretty much broken right now because of
> > > all
> > > these changes, but I could not start them to check. How do I run the
> > > tests
> > > with bjam again?
> > > 
> > > ------------------------------------------------------------------------
> > > --
> > > ---- Live Security Virtual Conference
> > > Exclusive live event will cover all the ways today's security and
> > > threat landscape has changed and how IT managers can respond.
> > > Discussions
> > > will include endpoint security, mobile security and the latest in
> > > malware
> > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > _______________________________________________
> > > Cppqed-support mailing list
> > > Cpp...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cppqed-support

[Cppqed-support] BlitzCVS_compatibility and BoostIntegration

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

Dear András,

I have transferred and adjusted the relevant commits for the cmake build 
system to BlitzCVS_compatibility. The result is in raimar/BlitzCVS_cmake.

Once you have prepared everything in master I will merge this with 
BoostIntegration and adjust Cmake so that it picks up the local boost version.

Maybe we can skype on thursday (tomorrow is a holiday in Austria)?

Best regards
Raimar

[Cppqed-support] Mac OS support, getLibs.sh

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

Dear András,

I updated my Mac to Lion and as a consequence tried to improve the Mac support 
a bit.

I have pushed two more commits to raimar/cmake:

* gcc 4.2 is now detected and the targets for the four script that would not 
compile with this version are removed. Xcode 4 still ships with gcc 4.2, this 
doesn't seem to change any time soon.

* I added install targets for the scripts and the libraries to the cmake 
framework. Under Linux it is the responsibility of the user to install to 
default locations or otherwise configure the dynamic linker so that the 
libraries are found (i.e. /etc/ld.so.conf.d, LD_LIBRARY_PATH) and to call 
ldconfig after installation. Under Mac the situation is more delicate. The 
library paths are hard coded to the binaries and dependent libraries, these 
paths are changed to the install prefix once everything is installed. This way 
scripts can be run without installing as before (including the possibility to 
move them around as long as the build dir exists) exactly as it always has 
been. Additionally it is now also possible to install everything and then the 
binaries no longer depend on the build directory. The install targets are 
still undocumented yet, but most users would expect them to exist anyways out 
of habit.

Also, I updated the documentation in raimar/Documentation. I completely 
rewrote the Mac OS section to make it better suited for users with Mac OS 10.7 
or newer: it is now possible to avoid the installation of the complete Xcode 
suite and install only the command line tools. This is only 136.37 MB instead 
of the 4.4 GB Xcode 3 download. Xcode 4 is not as large as Xcode 3 (1.8 GB) 
because Apple decided to factor out some lesser used libraries and tools. 
Unfortunately the command line tools are not available for 10.6 so there Xcode 
3 is still needed.

I found the installation of dependencies to be much faster and easier with the 
"Homebrew" package manager. It provides everything one needs for the C++QED 
compilation (including blitz mercurial version, but not FLENS) and installs 
much less dependencies compared to MacPorts because it makes better use of 
what is already present on the Mac OS system. The updated documentation is 
written with Homebrew in mind but states that it is also possible to satisfy 
the dependencies with MacPorts if this is already installed (which is now true 
because blitz has been updated to 0.10 in MacPorts).

I strongly suggest to drop Boost.Build support under Mac OS for now. It turns 
out that it only used to work because of a "bug" in Boost.Build, and as we 
have seen it was only possible to run the scripts from the root directory of 
the framework. Now this "bug" has been "fixed" and not even this works anymore. 
I suppose one would have to install everything in order to be able to run it, 
but I didn't test as Cmake works just fine. Telling from the bug reports 
dynamic linking on Mac OS really seems to be a mess and a constant source of 
confusion.

As I was working on the documentation branch anyway I included your 
technicalDefinitions.sty to make the branch self-contained. I had to use some 
workaround though documented in the commit message.

Finally I updated the getLibs.sh (it is in the branch raimar) to fix some 
problems. Instead of editing the Jamroot with sed (which did not work anymore) 
the script now gives hints how to call cmake or how to configure boost.build if 
the user chooses to install locally. The same tips concerning Boost.Build are 
also in the documentation now (edit user-config.jam or site-config.jam to 
provide library pathes). I removed Jamroot.hpc and Jamroot.macosx, because on 
teaser one can use the user-config.jam provided there or use cmake and on Mac 
Boost.Build is broken anyway.

That's all for now, best regards
Raimar

Re: [Cppqed-support] new tcc include scheme

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

Dear András,

I removed MCWF.h and added explicit template instantiations for BinarySystem. 
The result is in raimar/tccStaging, and it compiles in release mode again.

Best regards
Raimar

On Monday 13 August 2012 11:04:59 Andras Vukics wrote:
> Dear Raimar,
> 
> To me, everything you did here seems fine, I have only one small question:
> * Why is there a separate MCWF.h, and if there is, why does
> Evolution.h not include it ? EvolutionHigh.h used to pull in
> everything needed to evolve on quantumtrajectories.
> 
> Please check out the branch tccStaging where I have updated
> utils/testsuite and corrected a few small problems. The testsuite can
> be run simply with
> bjam (release)
> in the utils/testsuite folder.
> 
> I made a small test, and compilation dependencies have indeed
> decreased with this scheme:
> 
> quantumdata/impl/StateVector.tcc: 51 targets depends on it (used to be
> 58 targets)
> elements/frees/impl/Mode.tcc: 32 targets (58 targets)
> 
> utils/include/impl/Evolved.tcc: 50 targets (60 targets)
> utils/include/impl/BlitzArraySliceIterator.tcc: 50 targets (54 targets)
> 
> Thanks and best regards,
> András
> 
> 
> 
> On Sat, Aug 11, 2012 at 2:03 AM, Raimar Sandner
> 
> <rai...@ui...> wrote:
> > Dear András,
> > 
> > I have pushed raimar/tcc_new (and removed raimar/tcc). Tcc_new is already
> > branched from the latest r229 of master so that you don't need to merge
> > with the binary and composite changesets again.
> > 
> > I tried to stick to what we have discussed recently and also updated the
> > code organization rationales accordingly (raimar/Documentation).
> > 
> > Please note that I have also converted the pair
> > BlitzArraySlieIterator.h/tcc to the new style by defining the macros in a
> > separate file which is included in both headers. Now the tcc scheme is
> > consistent across the framework, but if you don't like this approach just
> > leave out the last commit when you merge.
> > 
> > Furthermore I have added LazyDensityOperator.tcc, and converted some of
> > the
> > frees headers to Free_.h so that Free.h can bundle Free_.h (or
> > impl/Free.tcc if present) together with ParsFree.h. However, I have not
> > changed the interaction header files in the same way yet. Currently these
> > are not used anywhere in the framework and Pars... headers are just
> > included in the corresponding interaction header file, so script users
> > have only to include this one header file anyway.
> > 
> > Best regards
> > Raimar
> > 
> > 
> > PS: probably the testsuites are pretty much broken right now because of
> > all
> > these changes, but I could not start them to check. How do I run the tests
> > with bjam again?
> > 
> > --------------------------------------------------------------------------
> > ---- Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Cppqed-support mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppqed-support

Re: [Cppqed-support] new tcc include scheme

[Andras V. <and...@ui...>]

Dear Raimar,

To me, everything you did here seems fine, I have only one small question:
* Why is there a separate MCWF.h, and if there is, why does
Evolution.h not include it ? EvolutionHigh.h used to pull in
everything needed to evolve on quantumtrajectories.

Please check out the branch tccStaging where I have updated
utils/testsuite and corrected a few small problems. The testsuite can
be run simply with
bjam (release)
in the utils/testsuite folder.

I made a small test, and compilation dependencies have indeed
decreased with this scheme:

quantumdata/impl/StateVector.tcc: 51 targets depends on it (used to be
58 targets)
elements/frees/impl/Mode.tcc: 32 targets (58 targets)

utils/include/impl/Evolved.tcc: 50 targets (60 targets)
utils/include/impl/BlitzArraySliceIterator.tcc: 50 targets (54 targets)

Thanks and best regards,
András



On Sat, Aug 11, 2012 at 2:03 AM, Raimar Sandner
<rai...@ui...> wrote:
> Dear András,
>
> I have pushed raimar/tcc_new (and removed raimar/tcc). Tcc_new is already
> branched from the latest r229 of master so that you don't need to merge with
> the binary and composite changesets again.
>
> I tried to stick to what we have discussed recently and also updated the code
> organization rationales accordingly (raimar/Documentation).
>
> Please note that I have also converted the pair BlitzArraySlieIterator.h/tcc
> to the new style by defining the macros in a separate file which is included in
> both headers. Now the tcc scheme is consistent across the framework, but if
> you don't like this approach just leave out the last commit when you merge.
>
> Furthermore I have added LazyDensityOperator.tcc, and converted some of the
> frees headers to Free_.h so that Free.h can bundle Free_.h (or impl/Free.tcc
> if present) together with ParsFree.h. However, I have not changed the
> interaction header files in the same way yet. Currently these are not used
> anywhere in the framework and Pars... headers are just included in the
> corresponding interaction header file, so script users have only to include
> this one header file anyway.
>
> Best regards
> Raimar
>
>
> PS: probably the testsuites are pretty much broken right now because of all
> these changes, but I could not start them to check. How do I run the tests
> with bjam again?
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support

[Cppqed-support] new tcc include scheme

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

Dear András,

I have pushed raimar/tcc_new (and removed raimar/tcc). Tcc_new is already 
branched from the latest r229 of master so that you don't need to merge with 
the binary and composite changesets again.

I tried to stick to what we have discussed recently and also updated the code 
organization rationales accordingly (raimar/Documentation).

Please note that I have also converted the pair BlitzArraySlieIterator.h/tcc 
to the new style by defining the macros in a separate file which is included in 
both headers. Now the tcc scheme is consistent across the framework, but if 
you don't like this approach just leave out the last commit when you merge.

Furthermore I have added LazyDensityOperator.tcc, and converted some of the 
frees headers to Free_.h so that Free.h can bundle Free_.h (or impl/Free.tcc 
if present) together with ParsFree.h. However, I have not changed the 
interaction header files in the same way yet. Currently these are not used 
anywhere in the framework and Pars... headers are just included in the 
corresponding interaction header file, so script users have only to include 
this one header file anyway. 

Best regards
Raimar


PS: probably the testsuites are pretty much broken right now because of all 
these changes, but I could not start them to check. How do I run the tests 
with bjam again?

Re: [Cppqed-support] cmake build system

[Andras V. <and...@ui...>]

Dear Raimar,

I have merged, pushed, and updated the documentation. I have also
merged part of the new composite architecture, so that now there is a
fine-grained control on the system characteristics of BinarySystem.
The same is under preparation for Composite.

> To make the documentation consistent we should also merge the cmake branch
> into BoostIntegration and BlitzCVS_compatibility. For the latter the cmake
> files have to be adjusted a little bit to remove all the serialization stuff and
> to detect the old cvs version of blitz++. I will do this once you have merged
> the cmake branch into the main branch.

I think in the BoostIntegration branch it is also necessary to remove
the enable-binary-output option because in this branch we assume that
the Boost dependency is header-only and furthermore the necessary
headers are included in the distribution.

Best regards,
András



>
> Best regards
> Raimar
>
> On Saturday 04 August 2012 00:49:00 Raimar Sandner wrote:
> > Dear András,
> >
> > I have pushed my first attempts with the cmake build system, and it works
> > quite well (dependency checking, library detection). Could you please test
> > the branch raimar/cmake?
> >
> > At the top level source directory, the steps are:
> >
> > mkdir build && cd build
> > cmake -DCMAKE_BUILD_TYPE=<type> ..
> >
> > where <type> is release or debug (unfortunately this is a bit clumsy).
> >
> > and then there are several options, e.g.
> >
> > make -j4
> > make -j4 VERBOSE=1
> > make -j4 1particle1mode
> > make -j4 fewer_scripts
> >
> > At the moment cmake checks for the required stuff (boost, blitz++, gsl,
> > gslcblas) and fails if one of these is not found. It also checks the
> > optional flens, boost-serialization and blitz++ with serialization support
> > and enables the corresponding features if these are found. If not, a
> > message is printed but the configuration succeeds. I would have to check if
> > it is possible to override the optional features and to disable them even
> > if they are detected (if this is desired?). If we are lucky this just works
> > out of the box for MacOS, I will test it next week.
> >
> > Best regards
> > Raimar
> >
> > ----------------------------------------------------------------------------
> > -- Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Cppqed-support mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppqed-support
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support

Re: [Cppqed-support] cmake build system

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

Dear András,

please have a look at raimar/cmake and raimar/Documentation.

The cmake method of compilation now works without modification on Mac OS X, 
leo3 and teazer. Additionally it supports easily importing the project into 
Xcode on Mac and kdevelop or Eclipse on Linux.

As we have discussed I have removed the Makefile and references to it from the 
documentation.

To make the documentation consistent we should also merge the cmake branch 
into BoostIntegration and BlitzCVS_compatibility. For the latter the cmake 
files have to be adjusted a little bit to remove all the serialization stuff and 
to detect the old cvs version of blitz++. I will do this once you have merged 
the cmake branch into the main branch.

Best regards
Raimar

On Saturday 04 August 2012 00:49:00 Raimar Sandner wrote:
> Dear András,
> 
> I have pushed my first attempts with the cmake build system, and it works
> quite well (dependency checking, library detection). Could you please test
> the branch raimar/cmake?
> 
> At the top level source directory, the steps are:
> 
> mkdir build && cd build
> cmake -DCMAKE_BUILD_TYPE=<type> ..
> 
> where <type> is release or debug (unfortunately this is a bit clumsy).
> 
> and then there are several options, e.g.
> 
> make -j4
> make -j4 VERBOSE=1
> make -j4 1particle1mode
> make -j4 fewer_scripts
> 
> At the moment cmake checks for the required stuff (boost, blitz++, gsl,
> gslcblas) and fails if one of these is not found. It also checks the
> optional flens, boost-serialization and blitz++ with serialization support
> and enables the corresponding features if these are found. If not, a
> message is printed but the configuration succeeds. I would have to check if
> it is possible to override the optional features and to disable them even
> if they are detected (if this is desired?). If we are lucky this just works
> out of the box for MacOS, I will test it next week.
> 
> Best regards
> Raimar
> 
> ----------------------------------------------------------------------------
> -- Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support

[Cppqed-support] cmake build system

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

Dear András,

I have pushed my first attempts with the cmake build system, and it works quite 
well (dependency checking, library detection). Could you please test the 
branch raimar/cmake?

At the top level source directory, the steps are:

mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=<type> ..

where <type> is release or debug (unfortunately this is a bit clumsy).

and then there are several options, e.g.

make -j4
make -j4 VERBOSE=1
make -j4 1particle1mode
make -j4 fewer_scripts

At the moment cmake checks for the required stuff (boost, blitz++, gsl, 
gslcblas) and fails if one of these is not found. It also checks the optional 
flens, boost-serialization and blitz++ with serialization support and enables 
the corresponding features if these are found. If not, a message is printed 
but the configuration succeeds. I would have to check if it is possible to 
override the optional features and to disable them even if they are detected 
(if this is desired?). If we are lucky this just works out of the box for 
MacOS, I will test it next week.

Best regards
Raimar

[Cppqed-support] C++QED segmentation fault when calculating negativity of the partial-transpose density operator in multipartite systems

[Andras V. <and...@ui...>]

Dear All,

It has now been reported several times that on certain architectures,
C++QED programs crash with segmentation fault when calculating
negativity of the partial-transpose density operator in multipartite
systems. This is only in release compilation mode, when bjam uses -O3
by default. In such cases it always transpired that the error is due
to over-optimization, and disappears when only -O1 is used for
optimization. Bjam has to be instructed to use this switch for
release-mode compilation. Cf. utils/Jamroot.reducedOptimization added
in revision #214.

Any deeper clarification of the error is welcome.

Best regards,
András



Dr. Andras Vukics
Institute for Theoretical Physics
University of Innsbruck

Re: [Cppqed-support] Problem with fuzzy time bugfix

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

Dear András,

thanks for merging. The bugfix branch is removed now.

On Thursday 03 May 2012 16:51:25 Andras Vukics wrote:
 
> > (*) Actually the stepsize can only decrease in the case ha_==0, li_!=0,
> > which might be inefficient. Maybe we should consider to increase the
> > stepsize if dpLimit is undershot significantly? Take for example a driven
> > three level atom in V configuration with a strong transition and a
> > metastable excited state (optical shelving). In periods where many
> > photons are scattered we need a small timestep, but when the atom is
> > "shelved" larger timesteps are sufficient.
> Yes, it's definitely a problem that the timestep can only decrease in
> this case. In the case of ha_=0, we should completely delegate
> timestep management to the Liouvillean part, so that it can also
> increase the timestep.
> 
> What we need is this:
> * timestep can increase if both the Hamiltonian and the Liouvillean
> agree with this
> * timestep should decrease if either requires this
> (if either ha_ or li_ is 0, it always agrees with an increase and
> never requires a decrease)
> * timestep should be Dt if both ha_ and li_ are 0, in which case the
> dc!=0 case doesn't even make sense, really (so this should maybe be
> filtered out when constructing MCWF_Trajectory)

Yes. The second requirement is already implemented, the third requirement is 
also implemented but maybe not in the right way. I agree that this is better 
handled in the constructor, the check in every timestep will always give the 
same result. Should we just set DtTry to Dt in the constructor if ha_==li_==0  
and throw an exception if dc != 0?

The first requirement is partially implemented for the case ha_!=0. For the 
other case maybe something like this?

if (!ha_ && dpOverDt*dtDid<undershootTolerance_*dpLimit_){
	getEvolved()->setDtTry(dpLimit_/dpOverDt);
}

Best regards
Raimar

Re: [Cppqed-support] Problem with fuzzy time bugfix

[Andras V. <and...@ui...>]

Dear Raimar,

All right, I seem to understand everything. I have merged and pushed,
so everyone can update now, and you can also remove your bugfix
branch. Thanks for clarifying this.

> (*) Actually the stepsize can only decrease in the case ha_==0, li_!=0, which
> might be inefficient. Maybe we should consider to increase the stepsize if
> dpLimit is undershot significantly? Take for example a driven three level atom
> in V configuration with a strong transition and a metastable excited state
> (optical shelving). In periods where many photons are scattered we need a
> small timestep, but when the atom is "shelved" larger timesteps are sufficient.

Yes, it's definitely a problem that the timestep can only decrease in
this case. In the case of ha_=0, we should completely delegate
timestep management to the Liouvillean part, so that it can also
increase the timestep.

What we need is this:
* timestep can increase if both the Hamiltonian and the Liouvillean
agree with this
* timestep should decrease if either requires this
(if either ha_ or li_ is 0, it always agrees with an increase and
never requires a decrease)
* timestep should be Dt if both ha_ and li_ are 0, in which case the
dc!=0 case doesn't even make sense, really (so this should maybe be
filtered out when constructing MCWF_Trajectory)

Best regards,
András

Re: [Cppqed-support] Problem with fuzzy time bugfix

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

Dear András,

On Wednesday 02 May 2012 19:14:50 you wrote:

> I think your explanation is correct, and this was more or less my
> explanation, too, although I didn't want to believe that adding up
> x/10. ten times will not result in x. (Do you think there is some
> floating point type in some library which doesn't have this problem?)

A quick search turned up gmplib, a gnu arbitrary precision library. One could 
use gmp rational numbers for stepsizes (converted to and from floats when 
interacting with gsl). Then ten times x/10 is guaranteed to be x. Whether this 
is practical depends on the overhead. 

> I experimented a bit with your bugfix, which seems perfect to me,
> although at the moment I don't quite understand where dtTry comes into
> play in the case when ha_=li_=0.

I agree that dtTry should not come into play for the case ha_==li_==0, and 
this is essentially my fix.

Where it did come into play: line 185 of MCWF_Trajectory.tcc, the call to 
*TimeStepBookkeeper::update*, where the new *DtTry* is always set to 
*stepToDo* for the case ha_==0. In revision #203 subsequent steps will then 
use this *DtTry* as *stepToDo*.

> However, a deeper problem in this case is that it is a waste to do 10
> steps between two outputs, but we could rather make one step always to
> the next output. I think it is rather in this way that this bug should
> be resolved. (Perhaps somehow already in the constructor of
> MCWF_Trajectory.)
> 
> What do you think?

Yes I agree, but  the bug3482771 branch does exactly this:

ha_ != 0: let dpLimit (if li_) and gsl manage the stepsize

ha_ == 0, li_!=0: let dpLimit alone manage the stepsize, and fix the bug that 
approaching an output time might decrease the stepsize. (*)

ha_ == li_ == 0: *stepToDo* will always evaluate to *Dt*, which means we jump 
right to the next output time. This is ensured by the li_ ? ... : Dt check in 
the assignment to *stepToDo*.

(*) Actually the stepsize can only decrease in the case ha_==0, li_!=0, which 
might be inefficient. Maybe we should consider to increase the stepsize if 
dpLimit is undershot significantly? Take for example a driven three level atom 
in V configuration with a strong transition and a metastable excited state 
(optical shelving). In periods where many photons are scattered we need a 
small timestep, but when the atom is "shelved" larger timesteps are sufficient.


Best regards
Raimar

> 
> On Thu, Apr 26, 2012 at 11:55 PM, Raimar Sandner
> 
> <rai...@ui...> wrote:
> > Dear András,
> > 
> > here is what I think is happening, let's take rev 203 and this example:
> > 
> > PumpedLossyMode_C++QED --kappa 0 --eta 0 --minitFock 2 --dc 0 --Dt 0.1
> > 
> > Dt is 0.1 and DtTry is 0.01 initially. This means
> > *MCWF_Trajectory<RANK>::coherentTimeDevelopment* is called 10 times, each
> > time *stepToDo* evaluates to 0.01. Due to rounding errors this does not
> > sum up to 0.1 exactly but to something that is slightly less then 0.1
> > (0.1 - 1e-17 in my case). Just before the next display
> > *coherentTimeDevelopment* is called once more with *stepToDo* evaluating
> > to 1e-17. In the next call to
> > *getEvolved()->update*, DtTry is updated to this very small value. As
> > there is no mechanism to increase DtTry again, the stepper will continue
> > with this DtTry also after the next display, and the trajectory seems to
> > be stuck (where really it is just extremely slow).
> > 
> > Even if initially Dt is not an even multiple of DtTry the problem might
> > occur eventually. DtTry can only become smaller whenever the trajectory
> > approaches the next display timestep, so sooner or later after some
> > displays the trajectory probably won't make any significant progress
> > anymore.
> > 
> > This also explains why this only happens if the system has no Hamiltonian
> > part. With a Hamiltonian the gsl integrator takes care of DtTry.
> > 
> > Please have a look at raimar/bug3482771, where I reverted the changes
> > introduced in rev 204 (except the check for li_ when calculating
> > *stepToDo*
> > which is independent from the rest). To fix the bug, I would suggest to
> > leave DtTry unchanged for the case ha_=0, there is no reason to decrease
> > DtTry only because we reach a display time. In my branch this is achieved
> > by calling *getEvolved()->update* with the argument *getDtTry()* instead
> > of *stepToDo*.
> > 
> > Best regards
> > Raimar

Re: [Cppqed-support] Problem with fuzzy time bugfix

[Andras V. <and...@ui...>]

Dear Raimar,

Sorry for the delay.

I think your explanation is correct, and this was more or less my
explanation, too, although I didn't want to believe that adding up
x/10. ten times will not result in x. (Do you think there is some
floating point type in some library which doesn't have this problem?)

I experimented a bit with your bugfix, which seems perfect to me,
although at the moment I don't quite understand where dtTry comes into
play in the case when ha_=li_=0.

However, a deeper problem in this case is that it is a waste to do 10
steps between two outputs, but we could rather make one step always to
the next output. I think it is rather in this way that this bug should
be resolved. (Perhaps somehow already in the constructor of
MCWF_Trajectory.)

What do you think?

Keep in touch,
András


On Thu, Apr 26, 2012 at 11:55 PM, Raimar Sandner
<rai...@ui...> wrote:
> Dear András,
>
> here is what I think is happening, let's take rev 203 and this example:
>
> PumpedLossyMode_C++QED --kappa 0 --eta 0 --minitFock 2 --dc 0 --Dt 0.1
>
> Dt is 0.1 and DtTry is 0.01 initially. This means
> *MCWF_Trajectory<RANK>::coherentTimeDevelopment* is called 10 times, each time
> *stepToDo* evaluates to 0.01. Due to rounding errors this does not sum up to
> 0.1 exactly but to something that is slightly less then 0.1 (0.1 - 1e-17 in my
> case). Just before the next display *coherentTimeDevelopment* is called once
> more with *stepToDo* evaluating to 1e-17. In the next call to
> *getEvolved()->update*, DtTry is updated to this very small value. As there is
> no mechanism to increase DtTry again, the stepper will continue with this
> DtTry also after the next display, and the trajectory seems to be stuck (where
> really it is just extremely slow).
>
> Even if initially Dt is not an even multiple of DtTry the problem might occur
> eventually. DtTry can only become smaller whenever the trajectory approaches
> the next display timestep, so sooner or later after some displays the
> trajectory probably won't make any significant progress anymore.
>
> This also explains why this only happens if the system has no Hamiltonian
> part. With a Hamiltonian the gsl integrator takes care of DtTry.
>
> Please have a look at raimar/bug3482771, where I reverted the changes
> introduced in rev 204 (except the check for li_ when calculating *stepToDo*
> which is independent from the rest). To fix the bug, I would suggest to leave
> DtTry unchanged for the case ha_=0, there is no reason to decrease DtTry only
> because we reach a display time. In my branch this is achieved by calling
> *getEvolved()->update* with the argument *getDtTry()* instead of *stepToDo*.
>
> Best regards
> Raimar
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support

Re: [Cppqed-support] Problem with fuzzy time bugfix

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

Dear András,

here is what I think is happening, let's take rev 203 and this example:

PumpedLossyMode_C++QED --kappa 0 --eta 0 --minitFock 2 --dc 0 --Dt 0.1

Dt is 0.1 and DtTry is 0.01 initially. This means 
*MCWF_Trajectory<RANK>::coherentTimeDevelopment* is called 10 times, each time 
*stepToDo* evaluates to 0.01. Due to rounding errors this does not sum up to 
0.1 exactly but to something that is slightly less then 0.1 (0.1 - 1e-17 in my 
case). Just before the next display *coherentTimeDevelopment* is called once 
more with *stepToDo* evaluating to 1e-17. In the next call to 
*getEvolved()->update*, DtTry is updated to this very small value. As there is 
no mechanism to increase DtTry again, the stepper will continue with this 
DtTry also after the next display, and the trajectory seems to be stuck (where 
really it is just extremely slow).

Even if initially Dt is not an even multiple of DtTry the problem might occur 
eventually. DtTry can only become smaller whenever the trajectory approaches 
the next display timestep, so sooner or later after some displays the 
trajectory probably won't make any significant progress anymore.

This also explains why this only happens if the system has no Hamiltonian 
part. With a Hamiltonian the gsl integrator takes care of DtTry.

Please have a look at raimar/bug3482771, where I reverted the changes 
introduced in rev 204 (except the check for li_ when calculating *stepToDo* 
which is independent from the rest). To fix the bug, I would suggest to leave 
DtTry unchanged for the case ha_=0, there is no reason to decrease DtTry only 
because we reach a display time. In my branch this is achieved by calling 
*getEvolved()->update* with the argument *getDtTry()* instead of *stepToDo*.

Best regards
Raimar

Re: [Cppqed-support] Problem with fuzzy time bugfix

[Andras V. <and...@ui...>]

Dear Raimar,

These trajectory halts are really annoying, especially because the
bugfix in question was introduced just against such halts.
And now you say that it is with the fix that you experience new halts?!

At the moment I don't have much time to look into this in depth, but I
would be more than happy to recant this fuzziness of time, since I've
been feeling uncomfortable with it throughout.

May I ask you to look a bit more into this, and to study also the
occurence of halts before revision #204, and why they occur only
without Hamiltonian evolution? (Though I have some explanation, it's
vague and would be difficult to present here.) Perhaps you can come up
with some better idea then how to solve this.

I will nevertheless try to find time to experiment as well.

Thanks a lot and best regards,
András




On Thu, Apr 26, 2012 at 11:34 AM, Raimar Sandner
<rai...@ui...> wrote:
>
> Dear András,
>
> the bugfix #3482771
>
> https://sourceforge.net/tracker/?func=detail&aid=3482771&group_id=187775&atid=922653
>
> introduces a problem with my script 2ParticlesRingCavityFull. I am comparing
> the branches raimar/private/stable (without the fix) and
> raimar/private/development (with the fix), the testcase is one of my production
> runs:
>
> 2ParticlesRingCavityFull --deltaCSin -10 --minitSin 0.1 --evol single \
>        --kappaCos 0.5 --etaSin 2 --fin2 5 --deltaCCos -10 --precision 6 \
>        --dc 0 --minitCos 0.1 --modeCavSin Sin --T 300 \
>        --cutoffSin 12 --modeCavCos Cos --pinit1 "(0.5 0 0.2 0)" \
>        --pinit2 "(-0.5 0 0.2 0)" --UnotCos -5 --kappaSin 0.5 \
>        --fin1 5 --seed 1001 --UnotSin -5 --Dt 1 --cutoffCos 5
>
> In the development branch, the trajectory comes to a halt almost completely
> around t=90, while stable continues to run. So I cannot use the version with
> the fix at the moment.
>
> The timesteps in development are only slightly smaller, on the order of 10^-5.
> In stable the timesteps are mostly on the order of 10^-4 and only sometimes
> 10^-5.
>
> As the simulation is quite slow I will provide a .sv file for t=89 to better
> reproduce the problem. From there maybe I can find out what is going on in the
> stepper.
>
> Is it true that the bug #3482771 only happens without Hamiltonian? Would it be
> possible to test for that and introduce the time fuzziness only for such
> systems?
>
> Best regards
> Raimar
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support

[Cppqed-support] Problem with fuzzy time bugfix

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

Dear András,

the bugfix #3482771

https://sourceforge.net/tracker/?func=detail&aid=3482771&group_id=187775&atid=922653

introduces a problem with my script 2ParticlesRingCavityFull. I am comparing 
the branches raimar/private/stable (without the fix) and 
raimar/private/development (with the fix), the testcase is one of my production 
runs:

2ParticlesRingCavityFull --deltaCSin -10 --minitSin 0.1 --evol single \
	--kappaCos 0.5 --etaSin 2 --fin2 5 --deltaCCos -10 --precision 6 \
	--dc 0 --minitCos 0.1 --modeCavSin Sin --T 300 \
	--cutoffSin 12 --modeCavCos Cos --pinit1 "(0.5 0 0.2 0)" \
	--pinit2 "(-0.5 0 0.2 0)" --UnotCos -5 --kappaSin 0.5 \
	--fin1 5 --seed 1001 --UnotSin -5 --Dt 1 --cutoffCos 5

In the development branch, the trajectory comes to a halt almost completely 
around t=90, while stable continues to run. So I cannot use the version with 
the fix at the moment.

The timesteps in development are only slightly smaller, on the order of 10^-5. 
In stable the timesteps are mostly on the order of 10^-4 and only sometimes 
10^-5.

As the simulation is quite slow I will provide a .sv file for t=89 to better 
reproduce the problem. From there maybe I can find out what is going on in the 
stepper.

Is it true that the bug #3482771 only happens without Hamiltonian? Would it be 
possible to test for that and introduce the time fuzziness only for such 
systems?

Best regards
Raimar