Auxilliary arrays are referencing used arrays

[Nick Papior]

This I think affects: born and born_spin tests

These cases are polarization calculations using the Harris Functional.
And I have found some inconsistencies from the two versions (trunk vs. ts-scf).
Doing
$> diff trunk/Src/ksv.F ts-scf/Src/ksv.F
$> diff trunk/Src/optical.F ts-scf/Src/optical.F
yields differences that may be important?

In particular it revolves re-using old array elements calculation arrays in the trunk whereas mine does not.

In mine all polarizations are equal, while trunk has the two first not equal the last.

I think that both optical and ksv should _not_ use auxiliary arrays from outside as that puts restraints and possible side-effects. This may indeed be such a case.

[Nick Papior (nickpapior)]

There where several other troubles with the optical code. I have now reduced the memory requirement of optical.F substantially.

Tests needs to be re-runned.

[Nick Papior (nickpapior)]

I marked the branch as "--fixed lp:1546615" but to no avail, o well.

[Alberto Garcia (albertog)]

I have targeted the bug to the two series (4.0 and trunk), to make it clear that it affects both branches.

I am not sure whether one can make a merge request to *two* different branches...
How were you planning to merge the bugfix into 4.0?

By the way, the syntax for marking a revision as fixing a bug is

   --fixes lp:XXXXX

[Nick Papior (nickpapior)]

Yes, I did this

   bzr commit --fixes lp:1546615 --file=log

and an automatic "reference" to the tag was made (see "Related branches" which was empty before my commit). However, it does not seem to figure out that the bug is "fixed". Perhaps the bug will first be removed once it has been tagged "Fix Released"?

1. I know I did it the "wrong" way around for the bug-fix. However, I think at some point we will all make this mistake. So perhaps it is a good way to learn. ;)
I plan to do a cherry-pick from the commit on trunk. That is the only way I see that trunk and rel-4.0 does not have two separate merge commits.

2. The merge-request documentation should be updated, in particular MAINTAINERS and DEVELOPERS typically have 2 options:
2a. A generic bug-fix, then a merge to the rel-X.Y branch and a subsequent merge onto the trunk should be performed.
2b. A generic feature merge, then a single direct merge into trunk is needed.

I will fix the documentation (please add an "OK" comment if you agree).

[Nick Papior (nickpapior)]

Come to think of it, shouldn't it just be:

1. cd rel-X.Y
2. bzr merge lp:~<>/siesta/fix-...
3. cd ../trunk
4. bzr pull
5. bzr merge ../rel-X.Y

In that way the merge is still present, no cherry-picking and "clean" history?

[Alberto Garcia (albertog)]

Exactly. That is what I meant yesterday. If rel-X.Y is only getting bug fixes, merging its changes into the trunk will pick them up and mark them as incorporated. The initial commit(s) of the release branch might be qualitatively different. These can be merged and then unwanted changes cleaned up, while still retaining the memory that they were merged.

[Nick Papior (nickpapior)]

Yes great, will add that to the documentation :)

--

Kind regards Nick Papior
On 18 Feb 2016 20:55, "Alberto Garcia" <email address hidden> wrote:

> Exactly. That is what I meant yesterday. If rel-X.Y is only getting bug
> fixes, merging its changes into the trunk will pick them up and mark
> them as incorporated. The initial commit(s) of the release branch might
> be qualitatively different. These can be merged and then unwanted
> changes cleaned up, while still retaining the memory that they were
> merged.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1546615
>
> Title:
> Auxilliary arrays are referencing used arrays
>
> Status in Siesta:
> Fix Committed
> Status in Siesta 4.0 series:
> In Progress
> Status in Siesta trunk series:
> Fix Committed
>
> Bug description:
> This I think affects: born and born_spin tests
>
>
> These cases are polarization calculations using the Harris Functional.
> And I have found some inconsistencies from the two versions (trunk vs.
> ts-scf).
> Doing
> $> diff trunk/Src/ksv.F ts-scf/Src/ksv.F
> $> diff trunk/Src/optical.F ts-scf/Src/optical.F
> yields differences that may be important?
>
> In particular it revolves re-using old array elements calculation
> arrays in the trunk whereas mine does not.
>
> In mine all polarizations are equal, while trunk has the two first not
> equal the last.
>
> I think that both optical and ksv should _not_ use auxiliary arrays
> from outside as that puts restraints and possible side-effects. This
> may indeed be such a case.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/siesta/+bug/1546615/+subscriptions
>