Re: [Users] Einstein Toolkit Meeting Minutes
On 27/03/17 18:19, Frank Loeffler wrote: > - Eloisa will look at boostedpuncture test case Hi all, this should now be fixed. Best, Eloisa ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes
Hi Present were: Bhavesh, Elo, Erik, Frank, Gwyneth, Ian H., Peter, Roberto, Steven, and Vassili Status on KNLs Some independently developed optionlists exist, but none are production-ready: - Erik's optionlist on Cori: in branch in simfactory2 - Frank will put his option list into simfactory. - Eloisa has one for Marconi + KNL, and will also put it in simfactory. Test suites and Jenkins: - Erik: optimizations on "jenkins" use optimization, performance difference ~8% - discussion about - whether to use optimizations or not / whether 8% are ok to loose - whether optimizations "dangerous" or not. - result for now: try to see if testsuites are broken and fix, if possible. - Eloisa will look at boostedpuncture test case - Roland will look at Spec test suites - Frank &| Roland will have a look at the hydro failure Piraha CST parsing (Stev): - caching parse-tree cuts down time practically to 0 - files holding cache (one per ccl file) will be within configurations - plan: new ticket, branch, eventually inclusion - parallelism problematic with Perl, but may not be needed anyway Gwyneth asked: - Constraints: what/how to use to calculate? - ML_AMD_Contstraints: uses ADM constraints, independent of evolution system - McLachlan: uses BSSN variables, no need to calculate ADM variables result: It does (and should) not really matter. Preferences for one or the other exist, and may depend on particular simulation specifics, but both should get the results to within numerical accuracy. - What thorn to use for which output type (basic/scalar/ascii) (Frank: It would probably be good to have this as overview on a page or so.) - Question about comment in bbh gallery example par file: "SummationByParts::sbp_upwind_deriv": not required for that parameter file would drop order of derivatives near boundary in some cases, but derivatives are not used here - ADMMass: how to measure - using initial data output (but that might differ from the one on the finite comp. grid) - ADMMass thorn: surface integralor - ADMMass thorn: volume integral (but needs thorn not in the toolkit to excise BHs) or - QuasiLocalMeasures: surface integral - time refinement factors on coarse grids - Stricter requirements on time step on very coarse grids than regular cfl factor may lead to instabilities (gauge evolution in particular). - Result: don't need to use if no instability seen. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes
Present: Frank, Steve, Zach, Roberto, Ian We had to use a new google hangout link. For some reason the old link didn't work for anyone anymore. Frank is still looking into alternatives, but was too busy in the last few weeks to follow up. Jenkins was down, but thanks for Ian is now alive again. piraha_everywhere will not go into the next release, because more test-time would be required for such a change than is left. Zach proposes to include hydro-analysis thorns. If you are interested to review those (quickly), and have time: please contact him. Llama might still go into this release, but would still require the necessary documentation / tests. Remember to enter the (new) doodle poll for FunHPC, if you are interested: http://doodle.com/poll/q7243awwn36vf6v5 If you are in Europe, remember that you might change to winter time next weekend, which would mean a different time for next week's ET call. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes
On Sun, Oct 16, 2016 at 07:01:13PM -0500, Frank Loeffler wrote: Please consider joining the weekly Einstein Toolkit phone call at 9:30 am US central time on Mondays. As usual, you can find instructions Present were: Erik, Josh, Roberto, Peter, Frank *** * The FunHPC work-day has been postponed. * *** Erik cannot make this Wednesday, so we had to postpone the work-day. A new Doodle poll for a new date is up, please add yourself if you are interested: http://doodle.com/poll/q7243awwn36vf6v5 With a new release coming up everyone is currently encouraged to point out even small things(tickets) they want to get fixed before things are frozen. If you have some of those, please mark them using the 'ET_2016_11' milestone. Also, please help resolving those that are marked in this way. It was also noted that the simfactory web pages are out of date, but at least the download-information will be fixed by Frank. The question of the future of Simfactory was raised as well, but with several both power users and developers not present this was postponed. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
Hi all, I have to teach on Mondays from 9:30AM--10:20AM (Central US time), so this semester, I will need to dial in a bit late to ET telecons (next Monday, MLK Day, is an exception). I would like to add two items to the 2015 wish list, having to do with making it easier for IllinoisGRMHD to be used with the rest of the Toolkit: 1) Modify HydroBase so that staggered A-fields are supported. The best strategy will require that we consider how initial data thorns might be made compatible with staggered or unstaggered A-field, as well as B-field-only evolutions. 2) Incorporate staggered prolongation/restriction operators into Carpet. -Zach * * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University On Mon, Jan 12, 2015 at 12:12 PM, Frank Loeffler kn...@cct.lsu.edu wrote: Present were: Erik, Ian, Steve, Frank, Peter, Barry, Josef, Roland, (problems with audio), and others I don't remember anymore (sorry, but they also didn't speak up) We first talked about plans for 2015. Mentioned were: - ET meeting in Europe, doodle poll about location and time - either in Italy (close to MG meeting) or Sweden (Micra) - either mid-July or mid-end August - Improving timelevel handling and making Carpet more flexible wrt time prolongation orders etc (https://trac.einsteintoolkit.org/ticket/620) - Dependency-based scheduling, to avoid errors and allow potential parallelization - Make tests independent of number of processes, or run on the right number (https://trac.einsteintoolkit.org/ticket/1075, https://trac.einsteintoolkit.org/ticket/1230). - Get tickets under control (https://trac.einsteintoolkit.org/ticket/1698) - Adding some Hydro analysis tools used by Frank and the Parma group - Working on Chemora, adding to the ET eventually - Getting some more interesting single-NS initial data into the ET - Adding Llama. Since Llama is public now, and officially released there would need to be a chaperon. - Including an elliptic solver Specific tickets/issues mentioned were - having a type that is CCTK_INT8 by default on 64-bit platforms Here the consensus seems to be that using CCTK_INT as platform-dependent type should be ok. - Adding a new type CCTK_INT16 - Merging the McLachlan rewrite branch There is a wiki page about that: https://docs.einsteintoolkit.org/et-docs/Rewrite_McLachlan If nobody objects this looks like to be happening soon. - The Jenkins Server will move to the PI. Erik and Ian will coordinate on that, and Frank volunteered to help. - McLachlan will move to bitbucket. The timeframe was not fixed, but is expected to be soonish. Frank ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes
Present were: Erik, Ian, Steve, Frank, Peter, Barry, Josef, Roland, (problems with audio), and others I don't remember anymore (sorry, but they also didn't speak up) We first talked about plans for 2015. Mentioned were: - ET meeting in Europe, doodle poll about location and time - either in Italy (close to MG meeting) or Sweden (Micra) - either mid-July or mid-end August - Improving timelevel handling and making Carpet more flexible wrt time prolongation orders etc (https://trac.einsteintoolkit.org/ticket/620) - Dependency-based scheduling, to avoid errors and allow potential parallelization - Make tests independent of number of processes, or run on the right number (https://trac.einsteintoolkit.org/ticket/1075, https://trac.einsteintoolkit.org/ticket/1230). - Get tickets under control (https://trac.einsteintoolkit.org/ticket/1698) - Adding some Hydro analysis tools used by Frank and the Parma group - Working on Chemora, adding to the ET eventually - Getting some more interesting single-NS initial data into the ET - Adding Llama. Since Llama is public now, and officially released there would need to be a chaperon. - Including an elliptic solver Specific tickets/issues mentioned were - having a type that is CCTK_INT8 by default on 64-bit platforms Here the consensus seems to be that using CCTK_INT as platform-dependent type should be ok. - Adding a new type CCTK_INT16 - Merging the McLachlan rewrite branch There is a wiki page about that: https://docs.einsteintoolkit.org/et-docs/Rewrite_McLachlan If nobody objects this looks like to be happening soon. - The Jenkins Server will move to the PI. Erik and Ian will coordinate on that, and Frank volunteered to help. - McLachlan will move to bitbucket. The timeframe was not fixed, but is expected to be soonish. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
Let's have a poll to find a good time for the telecon. -erik On Jan 12, 2015, at 13:21 , Zach Etienne zache...@gmail.com wrote: Hi all, I have to teach on Mondays from 9:30AM--10:20AM (Central US time), so this semester, I will need to dial in a bit late to ET telecons (next Monday, MLK Day, is an exception). I would like to add two items to the 2015 wish list, having to do with making it easier for IllinoisGRMHD to be used with the rest of the Toolkit: 1) Modify HydroBase so that staggered A-fields are supported. The best strategy will require that we consider how initial data thorns might be made compatible with staggered or unstaggered A-field, as well as B-field-only evolutions. 2) Incorporate staggered prolongation/restriction operators into Carpet. -Zach * * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University On Mon, Jan 12, 2015 at 12:12 PM, Frank Loeffler kn...@cct.lsu.edu wrote: Present were: Erik, Ian, Steve, Frank, Peter, Barry, Josef, Roland, (problems with audio), and others I don't remember anymore (sorry, but they also didn't speak up) We first talked about plans for 2015. Mentioned were: - ET meeting in Europe, doodle poll about location and time - either in Italy (close to MG meeting) or Sweden (Micra) - either mid-July or mid-end August - Improving timelevel handling and making Carpet more flexible wrt time prolongation orders etc (https://trac.einsteintoolkit.org/ticket/620) - Dependency-based scheduling, to avoid errors and allow potential parallelization - Make tests independent of number of processes, or run on the right number (https://trac.einsteintoolkit.org/ticket/1075, https://trac.einsteintoolkit.org/ticket/1230). - Get tickets under control (https://trac.einsteintoolkit.org/ticket/1698) - Adding some Hydro analysis tools used by Frank and the Parma group - Working on Chemora, adding to the ET eventually - Getting some more interesting single-NS initial data into the ET - Adding Llama. Since Llama is public now, and officially released there would need to be a chaperon. - Including an elliptic solver Specific tickets/issues mentioned were - having a type that is CCTK_INT8 by default on 64-bit platforms Here the consensus seems to be that using CCTK_INT as platform-dependent type should be ok. - Adding a new type CCTK_INT16 - Merging the McLachlan rewrite branch There is a wiki page about that: https://docs.einsteintoolkit.org/et-docs/Rewrite_McLachlan If nobody objects this looks like to be happening soon. - The Jenkins Server will move to the PI. Erik and Ian will coordinate on that, and Frank volunteered to help. - McLachlan will move to bitbucket. The timeframe was not fixed, but is expected to be soonish. Frank ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter schnet...@gmail.com http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
On 12 Jan 2015, at 18:12, Frank Loeffler kn...@cct.lsu.edu wrote: Present were: Erik, Ian, Steve, Frank, Peter, Barry, Josef, Roland, (problems with audio), and others I don't remember anymore (sorry, but they also didn't speak up) We first talked about plans for 2015. Mentioned were: - Including an elliptic solver To clarify, I meant including the CT_MultiLevel elliptic solver from the CosmoToolkit, as per https://trac.einsteintoolkit.org/ticket/1676. We just need to add an example to the gallery page, and then it can be added. -- Ian Hinder http://members.aei.mpg.de/ianhin signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes (September 22, 2014).
On Mon, Sep 22, 2014 at 11:21:43PM -0400, Barry Wardell wrote: Please go ahead and try it out, and report any outstanding issues. What is the status of Outflow? The still current svn thornlist lists its github repo as the one to be used, while the new git thornlist points (obviously) to the new git repo on bitbucket. Was the source/history from github used for the new repository? Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes (September 22, 2014).
Present: Ian, Roland, Eloisa Bentivegna, Frank, Zach, Barry, Peter, Steve, Erik Git transition: * Ian is testing the git repositories with Jenkins * need someone to test with GetComponents * commit messages will likely not work, will open up mailing list for bitbucket once first commit comes in * transition is ready to go, Frank has turned off svn commits and Barry will re-generate the git repositories * with the exception of simfactory we will also convert the other repositories https://docs.einsteintoolkit.org/et-docs/Repository_transition * Frank, Barry, Ian, Erik, Roland can add committers (and new admins) to bitbucket repos, add new committers as needed. Committers need bitbucket accounts. MDH code: * vector potential code in ET: need science driver. Poll ET list for interest, approach main users of MHD code directly. Yours, Roland signature.asc Description: OpenPGP digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes
Hi Present at todays meeting were: Roland, Jonah, Erik, Matt, Steve, Peter, Frank. We've talked about a couple of active tickets, in particular: - 1396: GetComponents: Display prompts of executed commands (discussion) Steve will look into bash-magic (or something else) to solve this. - 1517: Make Simfactory tell you what it's doing (discussion) Steve accepted the ticket. - 1388: New thorn MemSpeed (reviewed ok) Erik will add the thorn to the ET thornlist. - 1651: Problems with expansions in parameter files (new patch) Roland will look at the new patch. Nobody really tested the new git transition repositories, but at least Steve and Peter volunteered to do so soon. The URL for the thornlist to test is: https://svn.einsteintoolkit.org/manifest/trunk/git_testing.th Frank Loeffler signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes (August 11, 2014).
On 12 Aug 2014, at 16:06, Erik Schnetter schnet...@cct.lsu.edu wrote: On Aug 11, 2014, at 11:47 , Peter Diener die...@cct.lsu.edu wrote: Minutes from the Einstein Toolkit Meeting on August 11, 2014. Present: Frank, Peter, Barry, Josef, Ian, Steve, Josh, Jonah. Tickets: 778: PittNullCode is slow to compile. Frank is not sure what to do about it. According to Josef there is a constraint function that is slow. Josef usually does not compile this file. Ask Bela and or Roland about suggestions about what to do. Check if newer Intel compilers compiles it faster. Is it an option to remove it from ET. If I recall correctly, then this function is written in a whole-array style. Rewriting this with explicit index operations and surrounding it by a loop should improve compile time significantly. Roland already did this, and saw a speed improvement (see the ticket). I believe this improvement only helped with older compilers though. With 14.0.0, the file still takes 20 minutes to compile. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
On 17 Jul 2014, at 16:19, Frank Loeffler kn...@cct.lsu.edu wrote: Hi, On Thu, Jul 17, 2014 at 12:21:46PM +0200, Bruno Coutinho Mundim wrote: They look good to me. Should we distribute a commit-msg hook for the client to enforce the policy Thorn: in the commit messages? We could provide one. We cannot enforce people installing it. and on top of that set up the server to reject unformatted messages? That is probably the better option. Although I would only see it as help to not forget about it, not an enforcement really (although technically it is the same). We cannot disallow anything else than thorn names before the : (we might have commit touching multiple thorns), so we cannot technically prevent something like somewhere: changed something. But we don't need to technically enforce everything anyway. The reason for needing the thorn: prefix on the merged repositories is that the original commit message would have been written under the assumption that the reader knew which thorn was being modified, since there was just that thorn in the repository. With a merged repository, a such a message would not have that context, and would therefore convey less information. Hence we add the extra information for these messages. For the future, people should just write a commit message which makes sense in the context of the arrangement repository. If the commit just touches a single thorn, it's logical to use such a prefix, so that the reader gets some context for the change. I don't think it's necessary to enforce or even check this; it's just a useful convention. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Present were: Erik, Barry, Roland, Yosef, Josh Git transition: * need testers for new arrangements * convert remaining repositories on https://docs.einsteintoolkit.org/et-docs/Version_control including the undecided ones in the Miscellaneous repositories section Stalls on stampede: * not much news, Yosef can avoid the stalls using 20 nodes instead of 16 * check if created tmp files are valid hdf5 files or not Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlPWa4cACgkQTiFSTN7SboXRBgCfbX/NihJkWMQQF7fW/YLz6K55 YqYAn0yY7gXfroz/mCdmJ1AR6OR+8PjQ =XvHN -END PGP SIGNATURE- ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
On Thu, Jul 17, 2014 at 10:24 AM, Frank Loeffler kn...@cct.lsu.edu wrote: * Some of the commits creating tags also introduce changes to the tree (files). These commits were automatically created by the cvs2svn script. Why is that a problem? Does the conversion choke if commits do multiple things at once? The problem is that tags are not commits, they are supposed to be permanent pointers to a specific commit. They are never supposed to change and they cannot introduce changes to the tree. This is conceptually the same in svn, but not strictly enforced (since tags are really just copies of the code at another point in the svn directory tree). The problem happens when multiple thorns each have tags which also contain changes to the tree. A tag is just a pointer to a commit and can't point to two different commits at the same time. The solution I've used in instances where this happens is to create a new branch and merge all of the commits into that branch. * Some branches/tags (e.g. STABLE, LATEST) were not created at the same time across different repositories. None of the ones that I encountered had what I would useful content (e.g. having a STABLE tag pointing to some point long in the past is not particularly useful). I agree. We would very likely be better off without them. That makes things easier. I have a full list of tags/branches that have been omitted from the merged repositories so that we're sure we're not missing something. Right now that list is (not all of these are present in all arrangements/thorns): Branches: start El-Kharma dp Tags: LATEST STABLE v1 v_1 r1 V1 JTHORN_INIT JT_2002_08_18 jthorn_20050318 gr_qc LOCALINTERP_INIT Rel-0-1 I have now finished converting all of the repositories listed in the Version Control page of the wiki https://docs.einsteintoolkit.org/et-docs/Version_control. The results are available at: https://bitbucket.org/barrywardell/cactustest https://bitbucket.org/barrywardell/cactuspugh https://bitbucket.org/barrywardell/cactusnumerical https://bitbucket.org/barrywardell/pittnullcode https://bitbucket.org/barrywardell/cactusbase A couple of minor things came up in the conversion process: * I created a merged CactusNumerical as a more difficult test than CactusBase before noticing that it wasn't listed on the wiki page. It may be that we don't need this arrangement merged. * I included both CactusPUGH and CactusPUGHIO thorns (IOHDF5 and IOHDF5Util) in the same arrangement. It may be that they should be kept separate. Barry ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
Hi, On Thu, Jul 17, 2014 at 12:21:46PM +0200, Bruno Coutinho Mundim wrote: They look good to me. Should we distribute a commit-msg hook for the client to enforce the policy Thorn: in the commit messages? We could provide one. We cannot enforce people installing it. and on top of that set up the server to reject unformatted messages? That is probably the better option. Although I would only see it as help to not forget about it, not an enforcement really (although technically it is the same). We cannot disallow anything else than thorn names before the : (we might have commit touching multiple thorns), so we cannot technically prevent something like somewhere: changed something. But we don't need to technically enforce everything anyway. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
On Thu, Jul 17, 2014 at 10:19 AM, Frank Loeffler kn...@cct.lsu.edu wrote: We could provide one. We cannot enforce people installing it. and on top of that set up the server to reject unformatted messages? That is probably the better option. Although I would only see it as help to not forget about it, not an enforcement really (although technically it is the same). We cannot disallow anything else than thorn names before the : (we might have commit touching multiple thorns), so we cannot technically prevent something like somewhere: changed something. But we don't need to technically enforce everything anyway. This is a good point. While it seems like a good general guideline to have the thorn name as a prefix in any commit message, I'm not convinced it is a good idea to strictly enforce it. For example, what about commits that modify several thorns at once? Carpet has a policy like this; in general commit messages are prefixed by the thorn name, but occasionally there will be a message which changes many thorns at once and doesn't adhere to this convention. ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
On 07/17/2014 04:35 PM, Barry Wardell wrote: On Thu, Jul 17, 2014 at 10:19 AM, Frank Loeffler kn...@cct.lsu.edu wrote: We could provide one. We cannot enforce people installing it. and on top of that set up the server to reject unformatted messages? That is probably the better option. Although I would only see it as help to not forget about it, not an enforcement really (although technically it is the same). We cannot disallow anything else than thorn names before the : (we might have commit touching multiple thorns), so we cannot technically prevent something like somewhere: changed something. But we don't need to technically enforce everything anyway. This is a good point. While it seems like a good general guideline to have the thorn name as a prefix in any commit message, I'm not convinced it is a good idea to strictly enforce it. For example, what about commits that modify several thorns at once? Then we could prefix with Arrangement:. In any case I don't have strong feelings about it. It was just a suggestion to make the commit messages neater and motivate people to apply localized, atomic commits instead. Cheers, Bruno. Carpet has a policy like this; in general commit messages are prefixed by the thorn name, but occasionally there will be a message which changes many thorns at once and doesn't adhere to this convention. ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
I don't believe in automated mechanisms. Carpet has been using this policy for a long time. Many people use it without being told. Others don't -- they either don't care, or they can't be bothered because they have other things in mind when creating a commit, or they simply don't believe in reading commit messages. And then, there is the more important issue of knowing how to write a good commit message. Some people document their changes in commit messages (because they didn't write comments), others simply describe the changes in detail (as opposed to giving a high-level overview). Some use commit messages as forum to announce new features, or to explain how to use a new feature. If we truly want to change this, then we should - have a discussion on how we would like commit message to read - write this up on a brief, simple wiki page - refuse patches if the commit message is far below our standards (e.g. is offensive, or forgets to mention a major issue) To make this work, we need patches that are submitted together with submit messages. That is, people would need to publish their commits (e.g. in a Bitbucket clone), and a maintainer pulls them. -erik On Jul 17, 2014, at 15:31 , Bruno Coutinho Mundim bcm...@astro.rit.edu wrote: On 07/17/2014 04:35 PM, Barry Wardell wrote: On Thu, Jul 17, 2014 at 10:19 AM, Frank Loeffler kn...@cct.lsu.edu wrote: We could provide one. We cannot enforce people installing it. and on top of that set up the server to reject unformatted messages? That is probably the better option. Although I would only see it as help to not forget about it, not an enforcement really (although technically it is the same). We cannot disallow anything else than thorn names before the : (we might have commit touching multiple thorns), so we cannot technically prevent something like somewhere: changed something. But we don't need to technically enforce everything anyway. This is a good point. While it seems like a good general guideline to have the thorn name as a prefix in any commit message, I'm not convinced it is a good idea to strictly enforce it. For example, what about commits that modify several thorns at once? Then we could prefix with Arrangement:. In any case I don't have strong feelings about it. It was just a suggestion to make the commit messages neater and motivate people to apply localized, atomic commits instead. Cheers, Bruno. Carpet has a policy like this; in general commit messages are prefixed by the thorn name, but occasionally there will be a message which changes many thorns at once and doesn't adhere to this convention. ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter schnet...@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
On Wed, Jul 16, 2014 at 08:10:58PM -0400, Barry Wardell wrote: The conversion is mostly scripted, although there are necessarily a couple manual cleanup steps at the end. This manual cleanup is a somewhat time-consuming process, so if the new repository layouts look good to everyone it would be nice to transition to them soon-ish, before too much development happens in the thorn svn repositories. I am curious which steps have to be manual. If this is already a problem for CactusBase - how much of a problem will it be for larger repositories? CactusBase is probably one of the better behaved places. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] Einstein Toolkit Meeting Minutes
On Wed, Jul 16, 2014 at 11:30 PM, Frank Loeffler kn...@cct.lsu.edu wrote: I am curious which steps have to be manual. If this is already a problem for CactusBase - how much of a problem will it be for larger repositories? CactusBase is probably one of the better behaved places. The manual steps are to fix some minor inherent issues with the repositories, most of which seem to be a result of the CVS-SVN transition. I'm calling them minor as none of them affect the trunk/master branch or any of the Cactus or ET release branches. Some examples can be seen in the Cartoon2D repository https://bitbucket.org/cactuscode/cactusnumerical-cartoon2d/commits/all?page=5 : * There are extra branches (e.g. start, v1) which are not in any way connected to the rest of the history. These were created by the cvs2svn script. * Some of the commits creating tags also introduce changes to the tree (files). These commits were automatically created by the cvs2svn script. * Some branches/tags (e.g. STABLE, LATEST) were not created at the same time across different repositories. None of the ones that I encountered had what I would useful content (e.g. having a STABLE tag pointing to some point long in the past is not particularly useful). The reason these steps are manual is it because they require human intervention to determine whether the issues are important or can be ignored. Could you suggest an example of a more badly behaved arrangement? Barry ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] Einstein Toolkit Meeting Minutes
Hi, Present were: Roland, Erik, Barry, Peter, Frank, and Josh. Barry prepared a test conversion of CactusBase, including 'trunk/master' and ET_2014_05 so far. A few minor issues were noted: - empty one-line logs: will be fixed - empty authors: ok (from cvs2svn) - thorn-prefixes to be changed from [thorn] to thorn: - all branches will be included in next test - assumption: branch creation among thorns at same time - probably ok, and if not conversion scripts will complain Zach did not have more time for the Illinois code, but expects to within the next few weeks. Tickets: - 1641: Frank will change the default in Slab from AlltoAll to irecv/isend. This is expected to work, and changing it now will serve as test. (changed) Frank ~ ~ signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
