Hello all,
I am still getting occasional unexplainable rebuilds of my Cactus configuration. Eg. just now I modified GRHydro/Con2Prim and the system recompiles McLachlan. Is anyone else experiencing these? And do you have an inkling as to what could cause them? Input would be welcome (and I will look into this but need some better starting point even if is just a list of situations where a rebuild was triggered).
Yours, Roland
Yes, I experience the same. I tried a realclean, but after a complete rebuild they still occur.
I expect that there is an auto-generated file that changes when the thorn list changes. Could it be cctk.h itself?
-erik
On Mon, Sep 10, 2012 at 6:28 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
I am still getting occasional unexplainable rebuilds of my Cactus configuration. Eg. just now I modified GRHydro/Con2Prim and the system recompiles McLachlan. Is anyone else experiencing these? And do you have an inkling as to what could cause them? Input would be welcome (and I will look into this but need some better starting point even if is just a list of situations where a rebuild was triggered).
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
Hello all,
Yes, I experience the same. I tried a realclean, but after a complete rebuild they still occur.
I expect that there is an auto-generated file that changes when the thorn list changes. Could it be cctk.h itself?
I think I also have had these happen when I added a thorn to my thornlist. This at least should be straightforward to check.
I have also had unexpected compilations happen at least once when all I did was modify an existing thorn (though I might have modified its interface.ccl, in particular its public variables, as well though McLachlan should not care about public variables in GRHydro).
I also had issues where the system would not pick up a newly created configuration.ccl (to REQUIRE Carpet in Zelmani's QuadWaveExtract) unless I did a manual make sim-rebuild. This however I think might not be related.
Yours, Roland
On Mon, Sep 10, 2012 at 7:53 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
I also had issues where the system would not pick up a newly created configuration.ccl (to REQUIRE Carpet in Zelmani's QuadWaveExtract) unless I did a manual make sim-rebuild. This however I think might not be related.
This is unrelated.
-erik
Roland and I just corrected a problem with the auto-generated cctk_Configuration.h files. Maybe this corrected this problem?
-erik
On Mon, Sep 10, 2012 at 7:53 PM, Roland Haas <roland.haas@physics.gatech.edu
wrote:
Hello all,
Yes, I experience the same. I tried a realclean, but after a complete rebuild they still occur.
I expect that there is an auto-generated file that changes when the thorn list changes. Could it be cctk.h itself?
I think I also have had these happen when I added a thorn to my thornlist. This at least should be straightforward to check.
I have also had unexpected compilations happen at least once when all I did was modify an existing thorn (though I might have modified its interface.ccl, in particular its public variables, as well though McLachlan should not care about public variables in GRHydro).
I also had issues where the system would not pick up a newly created configuration.ccl (to REQUIRE Carpet in Zelmani's QuadWaveExtract) unless I did a manual make sim-rebuild. This however I think might not be related.
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
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Roland Haas