Present: Bill, Christopher, Helvi, Liu, Maria, Peter, Roland, Steve, Yosef, Zach
* Steve presented on the current state of presync ** all tests pass if presync is disabled ** working towards getting all tests passing with presync enabled ** Steve is merging in changes from master making sure things work again ** Fortran thorn are now working ** aim to have in ET in next release ** can go into master once there is interest and it does no harm ** interest in having it hooked up to NRPy+ on the code generation level
* Are we ready to turn off CactusCode.org? ** all in favor for moving ** Zach has some links to CactusCode.org that are in NRPy+ docs and that should be considered for a redirection ** https://bitbucket.org/einsteintoolkit/tickets/issues/2328 for suggested changes
* Zach's group has static trumped initial data thorn that, using correct gauge conditions gives static evolution * https://nbviewer.jupyter.org/github/zachetienne/nrpytutorial/blob/master/Tut... for the initial data, gauge condition notebook still to come
* Steve and Roland reported on issues with tutorial server apparently caused by timeouts ** Roland looking into alternative IO systems ** would also consider to migrate to somewhere else ** check if we can increase timeout values for jupyterhub to prevent the notebooks loosing their connection to the kernel
Yours, Roland
On Thu, Feb 6, 2020 at 10:47 AM Roland Haas rhaas@illinois.edu wrote:
- Are we ready to turn off CactusCode.org?
** all in favor for moving
I notice that this topic has been mentioned in the notes on the Einstein Toolkit mailing list, but has not been announced (in an email of its own), nor has it been mentioned on the Cactus mailing lists at all.
I understand that most of the active development these days is happening on the context of the Einstein Toolkit, and that maintaining the cactuscode.org domain web server seems like a burden, but Cactus is usable by itself, and publicly stating that Cactus is subsumed by the Einstein Toolkit greatly reduces the impact of the Toolkit on the computational science side. This probably won't affect physics funding, but this will make it more difficult to obtain funding from non-astrophysics sources. For example, CISE might ask why they should fund an astrophysics-only project where the maintainers decided deliberately to restrict the target audience of their software.
I'm sure it's not only Zach who has links to the web site https://en.wikipedia.org/wiki/Cactus_Framework.
-erik
On 6 Feb 2020, at 16:03, Erik Schnetter <schnetter@cct.lsu.edumailto:schnetter@cct.lsu.edu> wrote:
On Thu, Feb 6, 2020 at 10:47 AM Roland Haas <rhaas@illinois.edumailto:rhaas@illinois.edu> wrote:
* Are we ready to turn off CactusCode.orghttp://CactusCode.org? ** all in favor for moving
I notice that this topic has been mentioned in the notes on the Einstein Toolkit mailing list, but has not been announced (in an email of its own), nor has it been mentioned on the Cactus mailing lists at all. I understand that most of the active development these days is happening on the context of the Einstein Toolkit, and that maintaining the cactuscode.orghttp://cactuscode.org domain web server seems like a burden, but Cactus is usable by itself, and publicly stating that Cactus is subsumed by the Einstein Toolkit greatly reduces the impact of the Toolkit on the computational science side. This probably won't affect physics funding, but this will make it more difficult to obtain funding from non-astrophysics sources. For example, CISE might ask why they should fund an astrophysics-only project where the maintainers decided deliberately to restrict the target audience of their software.
I agree. For some of the non-NR projects I am now working on, I feel like I'm constantly missing and reinventing things that Cactus provides. Some of these projects might benefit from being Cactus thorns. Already, selling Cactus to people might be a little difficult, due to the learning curve and the extra "baggage" that you need to learn. This wouldn't be helped by Cactus being perceived as "a relativity code".
-- Ian Hinder Research Software Engineer University of Manchester, UK
So the question is, what do we do about the website? We don't have the time, person-power, or budget to maintain it. At present, the website is full of things that are horribly out of date and likely does more harm than good for anyone reading it.
We could make a website that's just a few well-chosen pages with a similar template to the ETK.
--Steve
On 2/7/2020 6:29 AM, Ian Hinder wrote:
On 6 Feb 2020, at 16:03, Erik Schnetter <schnetter@cct.lsu.edu mailto:schnetter@cct.lsu.edu> wrote:
On Thu, Feb 6, 2020 at 10:47 AM Roland Haas <rhaas@illinois.edu mailto:rhaas@illinois.edu> wrote:
- Are we ready to turn off CactusCode.org http://CactusCode.org?
** all in favor for moving
I notice that this topic has been mentioned in the notes on the Einstein Toolkit mailing list, but has not been announced (in an email of its own), nor has it been mentioned on the Cactus mailing lists at all. I understand that most of the active development these days is happening on the context of the Einstein Toolkit, and that maintaining the cactuscode.org http://cactuscode.org domain web server seems like a burden, but Cactus is usable by itself, and publicly stating that Cactus is subsumed by the Einstein Toolkit greatly reduces the impact of the Toolkit on the computational science side. This probably won't affect physics funding, but this will make it more difficult to obtain funding from non-astrophysics sources. For example, CISE might ask why they should fund an astrophysics-only project where the maintainers decided deliberately to restrict the target audience of their software.
I agree. For some of the non-NR projects I am now working on, I feel like I'm constantly missing and reinventing things that Cactus provides. Some of these projects might benefit from being Cactus thorns. Already, selling Cactus to people might be a little difficult, due to the learning curve and the extra "baggage" that you need to learn. This wouldn't be helped by Cactus being perceived as "a relativity code".
-- Ian**Hinder Research Software Engineer University of Manchester, UK
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 10 Feb 2020, at 16:37, Steven R. Brandt <sbrandt@cct.lsu.edumailto:sbrandt@cct.lsu.edu> wrote:
So the question is, what do we do about the website? We don't have the time, person-power, or budget to maintain it. At present, the website is full of things that are horribly out of date and likely does more harm than good for anyone reading it.
Hi Steve,
For time, person power and budget, how would this change if it were moved to be under the ET website?
Is the issue related to keeping the content up-to-date, or infrastructure issues like maintaining a separate webserver etc?
Deleting content which is out of date would help.
We could make a website that's just a few well-chosen pages with a similar template to the ETK.
Reducing the amount of administrative duplication is certainly desirable.
-- Ian Hinder Research Software Engineer University of Manchester, UK
On 2/11/2020 8:21 AM, Ian Hinder wrote:
On 10 Feb 2020, at 16:37, Steven R. Brandt <sbrandt@cct.lsu.edu mailto:sbrandt@cct.lsu.edu> wrote:
So the question is, what do we do about the website? We don't have the time, person-power, or budget to maintain it. At present, the website is full of things that are horribly out of date and likely does more harm than good for anyone reading it.
Hi Steve,
For time, person power and budget, how would this change if it were moved to be under the ET website?
I don't have a dollar or hour figure, but the svn repo is maintained by CCT, which sits on a server which has to be upgraded from time to time and there are svn client server version issues, etc. Similar issues apply to the webserver. The machine has to be upgraded from time to time, which includes going and getting new docs, etc. If we put a webserver on github and served cactuscode.org out of a docker image like we do for the ET, that would simplify upgrades and refreshing. It would also help us to document what the website does and make it possible to host it elsewhere if that ever becomes necessary or desirable.
My belief is that if we want to keep a cactuscode.org website, we should all help in updating it and making it worthwhile.
Is the issue related to keeping the content up-to-date, or infrastructure issues like maintaining a separate webserver etc?
Mostly, it's keeping the content relevant, but the website updated and running is a bit of a hassle too.
Deleting content which is out of date would help.
Right, but there's a lot of content and I don't have the time to go through it all--I don't think anyone does. I think we need to ask what the minimum thing is that we want. What are the critical set of pages?
We could make a website that's just a few well-chosen pages with a similar template to the ETK.
Reducing the amount of administrative duplication is certainly desirable.
It's more than desirable IMHO, it's necessary. Also, in recent months we've been working to decentralize administration and make sure that more than one person knows how to keep various things running. This is another opportunity to continue that trend.
--Steve
-- Ian**Hinder Research Software Engineer University of Manchester, UK
OK, I have this imported from SVN: https://github.com/EinsteinToolkit/cactuscode
Some of you already have commit rights on it. I'm happy to have more.
We apparently have a docker image in https://github.com/stevenrbrandt/et-websites already... and apparently I made it, though I don't remember doing so. Maybe I'm older than I think.
What I need is someone to help with the content.
--Steve
On 2/11/2020 10:04 AM, Steven R. Brandt wrote:
On 2/11/2020 8:21 AM, Ian Hinder wrote:
On 10 Feb 2020, at 16:37, Steven R. Brandt <sbrandt@cct.lsu.edu mailto:sbrandt@cct.lsu.edu> wrote:
So the question is, what do we do about the website? We don't have the time, person-power, or budget to maintain it. At present, the website is full of things that are horribly out of date and likely does more harm than good for anyone reading it.
Hi Steve,
For time, person power and budget, how would this change if it were moved to be under the ET website?
I don't have a dollar or hour figure, but the svn repo is maintained by CCT, which sits on a server which has to be upgraded from time to time and there are svn client server version issues, etc. Similar issues apply to the webserver. The machine has to be upgraded from time to time, which includes going and getting new docs, etc. If we put a webserver on github and served cactuscode.org out of a docker image like we do for the ET, that would simplify upgrades and refreshing. It would also help us to document what the website does and make it possible to host it elsewhere if that ever becomes necessary or desirable.
My belief is that if we want to keep a cactuscode.org website, we should all help in updating it and making it worthwhile.
Is the issue related to keeping the content up-to-date, or infrastructure issues like maintaining a separate webserver etc?
Mostly, it's keeping the content relevant, but the website updated and running is a bit of a hassle too.
Deleting content which is out of date would help.
Right, but there's a lot of content and I don't have the time to go through it all--I don't think anyone does. I think we need to ask what the minimum thing is that we want. What are the critical set of pages?
We could make a website that's just a few well-chosen pages with a similar template to the ETK.
Reducing the amount of administrative duplication is certainly desirable.
It's more than desirable IMHO, it's necessary. Also, in recent months we've been working to decentralize administration and make sure that more than one person knows how to keep various things running. This is another opportunity to continue that trend.
--Steve
-- Ian**Hinder Research Software Engineer University of Manchester, UK
On 11 Feb 2020, at 16:29, Steven R. Brandt <sbrandt@cct.lsu.edumailto:sbrandt@cct.lsu.edu> wrote:
OK, I have this imported from SVN: https://github.com/EinsteinToolkit/cactuscode
Some of you already have commit rights on it. I'm happy to have more.
We apparently have a docker image in https://github.com/stevenrbrandt/et-websites already... and apparently I made it, though I don't remember doing so. Maybe I'm older than I think.
What I need is someone to help with the content.
Hi Steve,
Thanks for importing it! I was just about to ask...
An alternative to hosting a web server with a docker image is to use Github Pages. The site is essentially static, and shouldn't need us to maintain a web server. This would remove any dependence on CCT infrastructure apart from the domain name, and remove any associated maintenance.
I've made a proof-of-principle attempt at this.
- Created a gh-pages branch in https://github.com/EinsteinToolkit/cactuscode on which to do my testing - Wrote a script to convert the PHP files to markdown; could have kept HTML but I prefer markdown as it enforces separation of the content from the presentation and is easier to edit - Ran the script on the current PHP files - Converted the site to use jekyll for the headers, footers, includes, etc - The site is available at https://einsteintoolkit.github.io/cactuscode.org/, but there are lots of assumptions in the files that it is served from "/", whereas here it is served from /cactuscode.orghttp://cactuscode.org. - To fix this, rather than editing all the URLs in the site, I've instead pointed my own domain to it.
You can see the result at http://cactuscode.ianhinder.net (https will start working in up to 24 hours, apparently). If we want to go ahead with this method, and if you have access to the cactuscode.orghttp://cactuscode.org domain, maybe you could create a CNAME record pointing
test.cactuscode.orghttp://test.cactuscode.org to einsteintoolkit.github.iohttp://einsteintoolkit.github.io
so we don't have to use my domain?
The automated conversion from PHP to markdown wasn't perfect; we will need to tidy it up a bit. But the idea now is that you can edit the markdown files, push to the repository, and they will automatically appear on the site. You can also preview it locally,
jekyll serve
if you have jekyll installed, or through docker, if you have docker installed:
docker run --rm -p 4000:4000 --volume="$PWD:/srv/jekyll" -it jekyll/jekyll jekyll serve
Visit http://localhost:4000 in either case to see the site.
If this sounds like a good way to go forward, we can start working through the files and fixing up the php to markdown conversion, deleting old content, etc.
-- Ian Hinder Research Software Engineer University of Manchester, UK
I like this a lot. We should talk about switching to this at the next call (tomorrow). It would be great if you could call in.
--Steve
On 2/12/2020 6:37 AM, Ian Hinder wrote:
On 11 Feb 2020, at 16:29, Steven R. Brandt <sbrandt@cct.lsu.edu mailto:sbrandt@cct.lsu.edu> wrote:
OK, I have this imported from SVN: https://github.com/EinsteinToolkit/cactuscode
Some of you already have commit rights on it. I'm happy to have more.
We apparently have a docker image in https://github.com/stevenrbrandt/et-websites already... and apparently I made it, though I don't remember doing so. Maybe I'm older than I think.
What I need is someone to help with the content.
Hi Steve,
Thanks for importing it! I was just about to ask...
An alternative to hosting a web server with a docker image is to use Github Pages. The site is essentially static, and shouldn't need us to maintain a web server. This would remove any dependence on CCT infrastructure apart from the domain name, and remove any associated maintenance.
I've made a proof-of-principle attempt at this.
- Created a gh-pages branch in
https://github.com/EinsteinToolkit/cactuscode%C2%A0on which to do my testing
- Wrote a script to convert the PHP files to markdown; could have kept
HTML but I prefer markdown as it enforces separation of the content from the presentation and is easier to edit
- Ran the script on the current PHP files
- Converted the site to use jekyll for the headers, footers, includes, etc
- The site is available at
https://einsteintoolkit.github.io/cactuscode.org/, but there are lots of assumptions in the files that it is served from "/", whereas here it is served from /cactuscode.org http://cactuscode.org.
- To fix this, rather than editing all the URLs in the site, I've
instead pointed my own domain to it.
You can see the result at http://cactuscode.ianhinder.net (https will start working in up to 24 hours, apparently). If we want to go ahead with this method, and if you have access to the cactuscode.org http://cactuscode.org domain, maybe you could create a CNAME record pointing
test.cactuscode.org <http://test.cactuscode.org> to einsteintoolkit.github.io <http://einsteintoolkit.github.io>so we don't have to use my domain?
The automated conversion from PHP to markdown wasn't perfect; we will need to tidy it up a bit. But the idea now is that you can edit the markdown files, push to the repository, and they will automatically appear on the site. You can also preview it locally,
jekyll serveif you have jekyll installed, or through docker, if you have docker installed:
docker run --rm -p 4000:4000 --volume="$PWD:/srv/jekyll" -it jekyll/jekyll jekyll serveVisit http://localhost:4000 in either case to see the site.
If this sounds like a good way to go forward, we can start working through the files and fixing up the php to markdown conversion, deleting old content, etc.
-- Ian**Hinder Research Software Engineer University of Manchester, UK
We now have an error page on the ETK website error404.html.
--Steve
On 2/6/2020 9:47 AM, Roland Haas wrote:
Present: Bill, Christopher, Helvi, Liu, Maria, Peter, Roland, Steve, Yosef, Zach
- Steve presented on the current state of presync
** all tests pass if presync is disabled ** working towards getting all tests passing with presync enabled ** Steve is merging in changes from master making sure things work again ** Fortran thorn are now working ** aim to have in ET in next release ** can go into master once there is interest and it does no harm ** interest in having it hooked up to NRPy+ on the code generation level
- Are we ready to turn off CactusCode.org?
** all in favor for moving ** Zach has some links to CactusCode.org that are in NRPy+ docs and that should be considered for a redirection ** https://bitbucket.org/einsteintoolkit/tickets/issues/2328 for suggested changes
Zach's group has static trumped initial data thorn that, using correct gauge conditions gives static evolution
https://nbviewer.jupyter.org/github/zachetienne/nrpytutorial/blob/master/Tut... for the initial data, gauge condition notebook still to come
Steve and Roland reported on issues with tutorial server apparently caused by timeouts
** Roland looking into alternative IO systems ** would also consider to migrate to somewhere else ** check if we can increase timeout values for jupyterhub to prevent the notebooks loosing their connection to the kernel
Yours, Roland
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Ian Hinder -
Roland Haas -
Steven R. Brandt