Hello Bernard,
Actually, Roland, do you know if this applies for the PGI compilers as well? Because that's what I was using.
I do not know if it applies to the PGI compiler as well. NICS'sannouncement before the upgrade (in one of the weekly ones) said that at least a re-link, possibly a full recompile is required. We no longer use PGI because it was found to be slower than Intel.
You can certainly pull the individual cfg file out of the trunk repository (https://svn.cct.lsu.edu/repos/numrel/simfactory2/trunk/mdb/optionlists/krake...) or do a switch of branch just for simfactory (most likely by removing your current simfactory checkout, changing the URL in the Thornlist to trunk and using GetComponent again). The same applis to the updated machine.ini and Kraken.sub files (minor changes only in them, ini file changes name of option list, Kraken.sub updates path to qsub).
The other option is for me to put the new config files into the Maxwell branch as well. Updates such as this were one reason why we used branches rather than tags I believe.
For the maintainers: any objections to this plan? My understanding is that I would also create a new tag ET_2011_10_v1 for this, yes?
Yours, Roland
Roland
Since Kraken changed, updating the released version is a very good idea. Creating a new tag is not necessary; a straight commit to the branch should do fine.
One uses tags to find earlier versions. It may be interesting to find out exactly what was originally released (hence we created a branch and a tag), but it will in the future probably not be interesting to track this particular change in a manner that goes beyond svn log, and hence creating a new tag is not necessary.
-erik
On Wed, Mar 14, 2012 at 4:26 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello Bernard,
Actually, Roland, do you know if this applies for the PGI compilers as well? Because that's what I was using.
I do not know if it applies to the PGI compiler as well. NICS'sannouncement before the upgrade (in one of the weekly ones) said that at least a re-link, possibly a full recompile is required. We no longer use PGI because it was found to be slower than Intel.
You can certainly pull the individual cfg file out of the trunk repository (https://svn.cct.lsu.edu/repos/numrel/simfactory2/trunk/mdb/optionlists/krake...) or do a switch of branch just for simfactory (most likely by removing your current simfactory checkout, changing the URL in the Thornlist to trunk and using GetComponent again). The same applis to the updated machine.ini and Kraken.sub files (minor changes only in them, ini file changes name of option list, Kraken.sub updates path to qsub).
The other option is for me to put the new config files into the Maxwell branch as well. Updates such as this were one reason why we used branches rather than tags I believe.
For the maintainers: any objections to this plan? My understanding is that I would also create a new tag ET_2011_10_v1 for this, yes?
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Thanks, Erik, Roland.
I grabbed the new cfg from the trunk using Roland's direct link, and it seems to work for me.
Bernard
P.S. I was using PGI before, and had done a fresh compile from scratch after the Kraken overhaul, as suggested. It still hit issues with the mpi.h -- the same issue encountered with Intel, so I suspect that the kraken_pgi.cfg needs an update, too. Assuming anyone uses it, of course. I'm happy to stick with Intel for the moment.
On 3/14/12 4:50 PM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
Roland
Since Kraken changed, updating the released version is a very good idea. Creating a new tag is not necessary; a straight commit to the branch should do fine.
One uses tags to find earlier versions. It may be interesting to find out exactly what was originally released (hence we created a branch and a tag), but it will in the future probably not be interesting to track this particular change in a manner that goes beyond svn log, and hence creating a new tag is not necessary.
-erik
On Wed, Mar 14, 2012 at 4:26 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello Bernard,
Actually, Roland, do you know if this applies for the PGI compilers as well? Because that's what I was using.
I do not know if it applies to the PGI compiler as well. NICS'sannouncement before the upgrade (in one of the weekly ones) said that at least a re-link, possibly a full recompile is required. We no longer use PGI because it was found to be slower than Intel.
You can certainly pull the individual cfg file out of the trunk repository
(https://svn.cct.lsu.edu/repos/numrel/simfactory2/trunk/mdb/optionlists/k raken-intel12.cfg) or do a switch of branch just for simfactory (most likely by removing your current simfactory checkout, changing the URL in the Thornlist to trunk and using GetComponent again). The same applis to the updated machine.ini and Kraken.sub files (minor changes only in them, ini file changes name of option list, Kraken.sub updates path to qsub).
The other option is for me to put the new config files into the Maxwell branch as well. Updates such as this were one reason why we used branches rather than tags I believe.
For the maintainers: any objections to this plan? My understanding is that I would also create a new tag ET_2011_10_v1 for this, yes?
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Hello Bernard,
Thanks, Erik, Roland.
No problem. Credit for finding proper options has to go to Christian Reisswig, Christian Ott and Cody Simmons.
I grabbed the new cfg from the trunk using Roland's direct link, and it seems to work for me.
Thank you for testing the file.
P.S. I was using PGI before, and had done a fresh compile from scratch after the Kraken overhaul, as suggested. It still hit issues with the mpi.h -- the same issue encountered with Intel, so I suspect that the kraken_pgi.cfg needs an update, too. Assuming anyone uses it, of course. I'm happy to stick with Intel for the moment.
My (pesonal) feeling is that the pgi configurtion file is likely to be retired. Most users seem to use the intel compiler (more familiar, fast code apparently). PGI had the advantage of being very picky about language standards and syntax. Made for a good test to check if we were using Intel/gcc specific features.
Yours, Roland
users@lists.einsteintoolkit.org