~nickpapior/siesta/mixing : changes

~nickpapior/siesta/mixing » Changes from revision 602

From Revision 583 to 564

Rev	Summary	Authors	Date
583	Fixed erroneous intent for filesOut, fixes lp:1640310 Fixed erroneous intent for filesOut, fixes lp:1640310 - The filesOut in TDDFT was edited _in-place_ in the dhscf routine with a subroutine only having intent(out). This meant that the previously set values were nullified upon return.	Nick Papior	7 years ago
582	Merged 4-1-r607..609 Merged 4-1-r607..609 - Fixes for tbtrans - Optimization in nlefsm - Fixed print-out for chemical potentials, lp:1638726	Nick Papior	7 years ago
581	Merged 4.1-r606 Merged 4.1-r606 - Complete update of manual to new layout	Nick Papior	7 years ago
580	Merge 4.1-605, patchlogs only (with criss-cross) Merge 4.1-605, patchlogs only (with criss-cross) This merge involved a criss-cross. From the bzr documentation: Criss-crosses occur in a branch's history if two branches merge the same thing and then merge one another, or if two branches merge one another at the same time. Criss-crosses cause problems because of the way merge works. Bazaar's default merge is a three-way merger; in order to merge OTHER into THIS, it must find a basis for comparison, BASE. Using BASE, it can determine whether differences between THIS and OTHER are due to one side adding lines, or from another side removing lines. Criss-crosses mean there is no good choice for a base. Selecting the recent merge points could cause one side's changes to be silently discarded. Selecting older merge points (which Bazaar does) mean that extra conflicts are emitted. The ``weave`` merge type is not affected by this problem because it uses line-origin detection instead of a basis revision to determine the cause of differences. Indeed, when requesting the most recent common revision before the merge: $ bzr log -rancestor:../4.1 --line 483.3.15: Alberto Garcia 2016-09-13 [merge] Changes to further standards compliance the answer was quite an old one. This is because the following patchlogs were already in the trunk, having been merged directly from 4.0 (at revisions 571 and 573): ------------------------ revno: 483.3.16 revision-id: nickpapior@gmail.com-20161006072528-03uhewjjhqwvc0s3 parent: albertog@icmab.es-20160913120042-79waws5ec5d2cc49 fixes bug: https://launchpad.net/bugs/1630827 committer: Nick Papior <nickpapior@gmail.com> branch nick: 4.0 timestamp: Thu 2016-10-06 09:25:28 +0200 message: Did not allow user control of SlabDipoleCorrection, fixes lp:1630827 ------------------------ revno: 483.3.17 revision-id: albertog@icmab.es-20161013124905-i8mcs29ht08lvsie parent: nickpapior@gmail.com-20161006072528-03uhewjjhqwvc0s3 fixes bug: https://launchpad.net/bugs/1625725 committer: Alberto Garcia <albertog@icmab.es> branch nick: 4.0 timestamp: Thu 2016-10-13 14:49:05 +0200 message: Fix bug 1625725 in 'nodes' basis-generation option ------------------------ They were also included in the to-be-merged revno 605 in 4.1, which had itself merged from 4.0 followed by "revert ." to sync the patchlogs. The "common ancestor" was reported as 483.3.15 since this is: revno: 483.3.15 [merge] revision-id: albertog@icmab.es-20160913120042-79waws5ec5d2cc49 the parent of 483.3.16 (see above), the oldest of the patchlogs to be merged. With hindsight, the direct merge in the trunk from 4.0 (with 4.1 already active and needing the same fixes) was ill-advised. Here is an edited summary of ideas exchanged while trying to establish a future policy about this: ----------------------------------------------------------------- Assuming that release branches are only for bug fixes: If a bug is discovered in 4.0 which does not apply to 4.1, it does not make sense to merge the substance of it into 4.1. It is a question of cosmetics whether the patchlogs should be merged, so that there is a clear record that all bugs discovered in past release branches have been taken care of in newer branches (either applied in substance or marked as "does not apply" by just importing the patchlogs). On the other hand, if the bug does apply, I think that the "commit only once in the repository" philosophy would require that the bug is committed first in 4.0, and (the same patch) merged into 4.1. For example, if you do now, in 4.1 (this was at revno 604): bzr missing --line ../4.0 you will get: [...] You are missing 2 revisions: 503: Alberto Garcia 2016-10-13 Fix bug 1625725 in 'nodes' basis-generation option 502: Nick Papior 2016-10-06 Did not allow user control of SlabDipoleCorrection, fixes ... but 4.1 does have the substance of the fix . It seems that the file changes from 4.0 were replicated in 4.1 without merging the patchlogs. Now one needs to double-check that the fix is actually applied in 4.1, either by "bzr log" (hoping that the committers are consistent in the subject lines) or in the code... There might be problems with transportation of unwanted changes (bits that do not quite apply), but this should be taken care of at the time of merging into 4.1. The net result is that there will be a single "main substance" commit for each "bug report" that applies to both versions. This commit will go into 4.0, and be merged (with the appropriate modifications) into 4.1, and then on into trunk (again, with the appropriate modifications, as always). -------------------------------------------------------end NOTE: As an example of a patchlog that "does not quite apply", here is a fix in 4.0 for an issue that had already been corrected in 4.1 (see the bug page for more details): -------------------- revno: 483.3.18 fixes bug: https://launchpad.net/bugs/1636100 committer: Nick Papior <nickpapior@gmail.com> branch nick: 4.0 timestamp: Mon 2016-10-24 09:27:38 +0200 message: Fixes non-colinear band calculation, fixes lp:1636100 -------------------- This patchlog comes to trunk via the merge of 4.0 patchlogs into 4.1. This merge was carried out with the command bzr merge --weave ../4.1 which did minimize the conflicts involved. It should be noted that the offending repeated patchlogs are not incorporated again into the branch history. (You can check this by doing bzr log -r 580 -n0 ) Hopefully future merges will not cause problems.	Alberto Garcia	7 years ago
579	Merge 4.1-604 Merge 4.1-604 Declare most variables (pending iso_var_st in fdict) Fixed cell constraints and the manual regarding this Fix electrode plane determination if Bloch expansions are used Fixed documentation with XML changes Fixed defaults for tbtrans and chemical potentials Updated obj_setup.sh to not mention the configure script Added gfortran.make and intel.make in Obj directory After FoX removal there was some changes that were not shipped to TS	Alberto Garcia	7 years ago
578	Merge 4.1 (595, 596) Merge 4.1 (595, 596) - Enabled default chemical potentials if they are named equally - Implement CML calls using an upgraded Src/wxml library (Remove FoX)	Alberto Garcia	7 years ago
577	Document subordinate make arguments, including 'override' Document subordinate make arguments, including 'override'	Alberto Garcia	7 years ago
576	Merging the TDDFT required the use of MatrixSwitch, forgot t... Merging the TDDFT required the use of MatrixSwitch, forgot to add in ts Now ts will also compile after the TDDFT merge	Nick Papior	7 years ago
575	Removed paste function from the TDDFT merge Removed paste function from the TDDFT merge	Nick Papior	7 years ago
574	Merged 4.1, r590-594 Merged 4.1, r590-594 - Corrected spin printout (Ramon Cuadrado), lp:1623415, lp:1623420 - Removed references to paste function - Enabled diagonal k-point sampling using a list for tbtrans - Bug-fix for PAO.BasisType nodes lp:1625725	Nick Papior	7 years ago
573	Merged 4.0, r503 Merged 4.0, r503 - Fixed BasisType nodes bug lp:1625725	Nick Papior	7 years ago
572	Merged 4.1, r587--589 Merged 4.1, r587--589 - Fixed MD CG method by reusing DM - Enabled super-cell bond-currents in tbtrans - Bug discovered which happened sometimes using linear kick	Nick Papior	7 years ago
571	Merged 4.0, r502 Merged 4.0, r502 No changes, changes equivalent to 4.1 r586.	Nick Papior	7 years ago
570	Merged 4.1, r586 Merged 4.1, r586 This merge contains several improvemenst: - Update linalg method such that only libsiestaBLAS/LAPACK may be used. All older codes have been removed. This is also reflected in the manual. Fixes lp:1627041 - Added citation of transiesta and PEXSI - Removed all configure related stuff, as it has not been updated in several years it has been decided to remove until we can get it back in. - Fixed problems with m_mpi_utils - Fixed SlabDipoleCorrection settings for backwards compatibility Fixes lp:1630827	Nick Papior	7 years ago
569	Implementation of Real-Time TDDFT Implementation of Real-Time TDDFT This implementation of Real-Time Time-Dependent Density Functional Theory (RT-TDDFT) is based on an earlier one (serial only) by Daniel Sanchez-Portal (ca. 2000-01) which had never been formally merged into Siesta. It currently only works for gamma-point calculations. Please see the manual for options, and the file Docs/branch-changes/NOTES.tddft for a technical overview. (Rafi Ullah, based on work by Daniel Sanchez-Portal)	Rafi Ullah	7 years ago
568	Removed dead directory in Tests/Reference Removed dead directory in Tests/Reference	Alberto Garcia	7 years ago
567	Fixes from 4.1: reclat calls, .ldau_proj files Fixes from 4.1: reclat calls, .ldau_proj files	Alberto Garcia	7 years ago
566	Fix double import in mpi_siesta (from 4.1) Fix double import in mpi_siesta (from 4.1)	Alberto Garcia	7 years ago
565	Standards-compliance fixes (from 4.1) (lp:1619437) Standards-compliance fixes (from 4.1) (lp:1619437)	Alberto Garcia	7 years ago
564	Fix MRRR switch-off (lp:1622526) (from 4.1) Fix MRRR switch-off (lp:1622526) (from 4.1)	Alberto Garcia	7 years ago

Older »