The Simulating eXtreme Spacetimes (SXS) collaboration is a multi-institutional collaboration dedicated to the simulation of extreme spacetimes in order to predict multi-messenger signals (gravitational wave, electromagnetic, and neutrino) from high-energy astrophysical events. This document describes various policies that members of the SXS collaboration are expected to adhere to in order to carry out effective collaborative research. One of the goals of these policies is to create an inclusive, supportive and harassment-free environment that nurtures junior researchers.
The SXS collaboration consists of a number of faculty and senior researchers that have agreed to use common resources (§7) in order to pursue collaborative research. The current faculty and senior researchers, hereafter referred to as senior members, are listed in §9.1.
SXS members are also the post-docs, graduate students, and undergradutae students who are working with a SXS senior member on SXS projects (§6). All SXS members are expected to adhere to the collaboration policies. If someone is unsure of somebody’s membership status they should consult the SXS executive committee (§3). Membership in the SXS collaboration does not guarantee authorship on SXS publications. SXS member institutions are all institutions with an SXS member.
New members must send an e-mail to the executive committee ([email protected]) acknowledging that they have read and agree to these SXS policies, including the code of conduct (§4) and publication policies (§8). For example:
Dear SXS executive committee,
I, NAME, acknowledge that I have read and agree with the SXS policies as outlined in the SXS Collaboration Policies document.
Best,
NAME
Faculty or senior researchers who are not members of the SXS
collaboration can be invited by the SXS executive committee to join the
SXS Collaboration. Prior to extending the invitation, an announcement
must be sent to [email protected] and the #general
channel of the SXS collaboration Slack (sxscollab.slack.com), giving
members a week to share any concerns about the new potential member.
Concerns may be sent either to the executive committee or anonymously to
the
ombudsperson (§4.1.2) or
advocate (§4.1.3). Suggested text:
Dear SXS members,
The SXS executive committee is looking for feedback on extending an invitation to NAME to join SXS as a faculty/senior researcher member. Please provide feedback either directly to the executive committee at [email protected], or anonymously through the SXS ombudsperson/advocate at [email protected] or [email protected] by DATE.
Best,
The SXS executive committee
SXS student and postdoc members who move on to a non-SXS institution as a postdoc must decide whether they want to remain as alumni members, and retain access to some SXS collaboration resources and adhere to SXS policies, or leave SXS and only retain access to public SXS resources. Regardless of the decision, any projects initiated before leaving an SXS institution continue to be governed by SXS policies until their completion, with continued access to any SXS resources that are required for the project. The student or postdoc should discuss with their advisor whether or not they wish to remain in the collaboration. If the advisor and student/postdoc agree that remaining in SXS will be mutually beneficial, the advisor will ask the executive committee for approval. The advisor will continue to supervise, be responsible for, and remain the point of contact for the student/postdoc. Specifically, the advisor will be responsible for ensuring correct access and usage of SXS resources such as computer time, codes, and SXS private data.
If a member decides to leave the collaboration, they may retain and use current copies of SXS codes, but are expected to offer authorship to the developers of the codes who have earned authorship rights as discussed in §8. The member leaving the collaboration can also transition to being an external collaborator and discuss with the executive committee what other SXS resources they can use. In all cases, members who leave may continue to use SXS resources to finish any projects that were started as SXS members. Additionally, any SXS code developers (see §7.1) who leave the collaboration and are no longer contributing to the code will retain any authorship rights they have for at least two years and at least five papers using the code.
If a current SXS student, postdoc, or alumni member is starting a faculty position, they may apply to the executive committee to become a new senior member. If the executive committee approves the request, the executive committee with then follow the procedures above by sending a collaboration-wide announcement.
SXS members can be members of other collaborations such as the LIGO Scientific Collaboration, the LISA Consortium, etc. If you believe there is a conflict between SXS policies and the policies of the other collaboration, please bring it to the attention of the executive committee so that the conflict can be resolved.
The responsibility of oversight of the SXS collaboration rests with the SXS executive committee.
The SXS Executive Committee has the following authority and responsibilities:
-
It has the authority and responsibility for allocating the grant funds from our collaborative grants, with the allocations being guided by our scientific goals and by the various intermediate benchmarks that the Executive Committee defines. For example, as spelled out in our current Fairchild funding proposal, the Executive Committee receives this authority from Saul Teukolsky, the Fairchild grant PI. Saul, in consultation with the co-PI Kip Thorne, has the authority to overrule the Executive Committtee’s funding allocation decisions for the Fairchild grant, though this will happen very rarely if ever. The Fairchild funds support people and activities at Caltech and Cornell. There are also funds for computing hardware. These hardware resources are open to all members of SXS. Note that grants for individual institutions are not overseen by the executive committee, but members should feel free to coordinate activities funded by these grants.
-
It has the authority and responsibility to keep itself informed about all research projects that are supported by our funds (their nature, progress, and anticipated duration).
-
It has the authority and responsibility to oversee and allocate SXS collaboration resources (§7).
-
It has the authority and responsibility to oversee and interpret the policies outlined in this document, including the code of conduct (§4) and publication policies (§8).
-
It has the authority and responsibility to modify these policies and to devise new policies for anything that is not covered by this document. SXS members may propose modifications or new policies by contacting a member of the executive committee or the advocate. All changes to the policies in this document will be announced to the collaboration in order to obtain feedback prior to their adoption.
-
It has the authority to remove a member who is no longer using SXS resources or who has seriously violated the SXS Code of Conduct.
The current SXS executive committee must decide when inviting a new faculty or senior researcher to join the collaboration whether to also invite them to join the executive committee.
In general, the SXS executive committee reaches decisions via majority vote. However, any decision that involves resources from a specific grant can be vetoed by the PI or co-PI of that grant.
The SXS collaboration will continue to exist until it is unanimously decided to disband the collaboration.
The Student/Postdoc advocate (§4.1.3) is a liason to the executive committee, and not a voting member. The SXS executive committee cannot assign the Advocate any tasks or responsibilities. This is to ensure that the Advocate is representing the students and postdocs, and is not a member of the executive committee.
It is very important that SXS is a positive, welcoming, and supportive environment for everyone. Therefore, we have adopted a code of conduct. All SXS members must provide written (email okay) agreement that they have read and will abide by the code of conduct (see example text in §2).
SXS has created the positions of ombudsperson and student-postdoc advocate with whom members can informally and confidentially discuss any concerns that they might have regarding conflicts, problems, violations of the code of conduct, or any other concerns they have. The current ombudsperson and student-postdoc advocate are listed in Appendix 9.2, and can be reached at [email protected] and [email protected]
With the goal of supporting our fellow group members in doing the best science we can, we expect that all members of the Simulating eXtreme Spacetimes collaboration
-
Behave professionally in a way that is welcoming and respectful to all participants.
-
Behave in a way that is free from any form of discrimination, harassment, or retaliation.
-
Treat each other with collegiality and respect and help to create a supportive working environment.
For more specific guidelines for appropriate conduct, we refer collaboration members to the “Ground Rules” section below, which is based on the LLVM Code of Conduct at https://llvm.org/docs/CodeOfConduct.html.
If you observe violations of the code of conduct, or have concerns about potential violations, we encourage you to formally report this to one or more members of the SXS Executive Committee. After investigation, the Executive Committee will work to resolve the situation, in consultation with parties involved and preserving confidentiality to the extent allowed by law, as outlined below.
If you have a concern about a code of conduct violation or potential violation, but you do not wish to report it formally, you can speak informally and confidentially about your concern with the SXS Ombudsperson (see below).
The Executive Committee will take appropriate action to ensure that all members of the collaboration meet the expectations of our code of conduct.
The Ombudsperson (email [email protected]) is a senior member of the collaboration, either faculty or a senior researcher, who offers confidential, neutral, and informal conflict resolution services to members of the SXS Collaboration. All collaboration members should feel free to contact the Ombudsperson to informally and confidentially discuss any concerns that they might have regarding conflicts, problems, violations of the code of conduct, or any other concerns they might have.
After speaking with Ombudsperson, if you wish, you can choose to ask the Ombudsperson to bring your concerns to the attention of the SXS Executive Committee or to other people at the appropriate institutions, and you can also choose to report your concerns formally to the SXS Executive Committee (as outlined below). Otherwise, unless there is a serious issue of safety, your conversations with the Ombudsperson will remain confidential.
We have adopted the same policy as the LIGO Scientific Collaboration Ombudsperson; see this document, replacing “LSC” with “SXS Collaboration”, and “LSC Spokesperson” with “the SXS Executive Committee”, for more details about the Ombudsperson’s role: https://dcc.ligo.org/public/0099/M1300006/001/LSCOmbudsperson.pdf
The executive committee will solicit volunteers for the position. The executive committee will choose the ombudsperson by holding an election with ranked-choice voting among those nominees that agreed to stand for election. The ombudsperson serves a two-year term.
The Student/Postdoc Advocate (email [email protected]) is someone who will advocate positively for the people in the collaboration with less power, specifically high school students, undergraduate students, summer REU students, grad students, and postdocs. It may sometimes be daunting to go to professors, so please feel free to talk to the Advocate about any issues and concerns you may have in the collaboration, especially concerns about culture and environment. The Advocate can bring up (anonymously) any of your concerns with the SXS executive committee if you wish. Otherwise, unless there’s a serious issue of safety, the Advocate will keep the Ombudsperson in the loop but otherwise keep your conversation confidential.
The SXS Advocate must be elected by the student and postdoc members of SXS, and be within two years of their Ph.D. (i.e. a senior graduate student or a new postdoc). The SXS executive committee will have a call for nominations and then consult with nominees to see if they are willing to be the advocate. If the SXS executive committee has any concerns with a nominee, they will discuss these concerns with the nominator. The SXS executive committee will then supervise an election among SXS student and postdoc members with ranked-choice voting among those nominees that agreed to stand for election. Once the list of candidates for SXS advocate is announced, the executive committee cannot change the candidate list (unless there is a serious violation of the SXS code of conduct). The Advocate is elected for a one-year term, and may be re-elected.
The Simulating eXtreme Spacetimes (SXS) Collaboration has the goal of supporting our fellow group members in doing the best science we can. To this end, we have a few ground rules that we ask people to adhere to:
-
be friendly and patient,
-
be welcoming,
-
be considerate,
-
be respectful,
-
be careful in the words that you choose and be kind to others, and
-
when we disagree, try to understand why.
This is not an exhaustive list of things that you can’t do. Rather, take it in the spirit in which it is intended — a guide to make it easier to communicate and participate in the community. This code of conduct applies to all spaces managed by the SXS Collaboration. This includes physical spaces at institutions with SXS group members; Slack channels, mailing lists, and bug trackers; SXS Collaboration events (such as the visiting institutions and workshops); and any other forums created by the collaboration uses for communication. It applies to all of your communication and conduct in these spaces, including emails, chats, things you say, slides, videos, posters, signs, or even t-shirts you display in these spaces. In addition, violations of this code outside these spaces may, in rare cases, affect a person’s ability to participate within them, when the conduct amounts to an egregious violation of this code. If you believe someone is violating the code of conduct, we ask that you report it by emailing one or more members of the SXS Executive Committee (see “Reporting” below). If you would rather not formally report your concern, you should feel free to discuss it informally and confidentially with the SXS Ombudsperson.
-
Be friendly and patient. During teleconferences and meetings, participants who wish to speak should feel free to type “hand up” or similar in the comment box, as needed, to get the chairs’ attention. Meeting/teleconference chairs are encouraged to make space for those unfamiliar with the topic of discussion to ask questions and engage.
-
Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, colour, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion or lack thereof, and mental and physical ability.
-
Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
-
Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the SXS Collaboration should be respectful when dealing with other members as well as with people outside the SXS Collaboration.
-
Be careful in the words that you choose and be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable. This includes, but is not limited to:
-
Violent threats or language directed against another person.
-
Discriminatory jokes and language.
-
Posting sexually explicit or violent material.
-
Posting (or threatening to post) other people’s personally identifying information (“doxing”).
-
Personal insults, especially those using racist or sexist terms.
-
Unwelcome sexual attention.
-
Advocating for, or encouraging, any of the above behavior.
-
-
In general, if someone asks you to stop, then stop. Persisting in such behavior after being asked to stop is considered harassment.
-
When we disagree, try to understand why. Disagreements, both social and technical, happen all the time, and SXS is no exception. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of communities comes from having a varied community, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.
If you believe someone is violating the code of conduct, you can always file a report by emailing one or more members of the SXS Executive Committee. All reports will be kept confidential.
If you believe anyone is in physical danger, please notify appropriate law enforcement first. If you are unsure what law enforcement agency is appropriate, please include this in your report and we will attempt to notify them.
Reports of violations of the code of conduct can be as formal or informal as needed for the situation at hand. If possible, please include as much information as you can. If you feel comfortable, please consider including:
-
Your contact info (so we can get in touch with you if we need to follow up).
-
Names (real, nicknames, or pseudonyms) of any individuals involved. If there were other witnesses besides you, please try to include them as well.
-
When and where the incident occurred. Please be as specific as possible.
-
Your account of what occurred. If there is a publicly available record (e.g. a mailing list archive or Slack logs) please include a link.
-
Any extra context you believe existed for the incident.
-
If you believe this incident is ongoing.
-
Any other information you believe we should have.
What happens after you file a report? (Following the LLVM process) — You will receive an email from the SXS Executive Committee member(s) you contacted, acknowledging receipt within 24 business hours (and we will aim to respond much quicker than that). If you do not receive an acknowledgment, please resend your report.
They will review the incident and try to determine:
-
What happened and who was involved.
-
Whether this event constitutes a code of conduct violation.
-
Whether this is an ongoing situation, or if there is a threat to anyone’s physical safety.
Once the contacted SXS Executive Committee members have a complete account of the events they will make a recommendation to the full Executive Committee as to how to respond. Responses may include:
-
Nothing, if we determine no violation occurred or it has already been appropriately resolved.
-
Providing either moderation or mediation to ongoing interactions (where appropriate, safe, and desired by both parties).
-
A private reprimand from the working group to the individuals involved.
-
An imposed vacation (i.e. asking someone to take a week off from a mailing list or Slack).
-
Escalation to the appropriate institutions.
-
Involvement of relevant law enforcement if appropriate.
If the situation is not resolved within one week, we will respond within one week to the original reporter with an update and explanation. Once we have determined our response, we will separately contact the original reporter and other individuals to let them know what actions (if any) will be taken. We will take into account feedback from the individuals involved on the appropriateness of our response, but we don’t guarantee we’ll act on it.
The scientific goals of the SXS collaboration are to develop codes that can be used to predict the gravitational waveforms and multi-messenger signals (electromagnetic and neutrino) from astrophysical sources targeted by current and future gravitational wave detectors. These sources include compact binary mergers, core-collapse supernovae, and accretion disks about compact objects (e.g. neutron stars and black holes).
The codes developed by members of the collaboration in pursuit of the aforementioned goals (whether they perform the numerical simulations of astrophysical sources, extract predictions of waveforms or signals from such sources, or are used to build models of the signals from such sources) are considered collaboration codes, and as such are available for all members of the collaboration. This applies whether or not the codes are open source.
Contributing to or using non-SXS codes does not fall under these policies. However, the executive committee must be consulted before using SXS computational resources with non-SXS codes.
The data produced by SXS codes in pursuit of the above scientific goals are considered collaboration data and are available for all members of the collaboration to use. Periodically the collaboration will release public catalogs of collaboration data, after which the data will be considered public data.
If SXS resources (§7) are used for other goals (e.g. proto-planetary disks, or white dwarf mergers, or LIGO thermal noise calculations), then the following apply:
-
The SXS executive committee can decide whether or not they wish to supervise the project.
-
The publication and data policies of the individual SXS codes will still apply to the project.
-
It is expected that code improvements for such purposes be merged into the SXS code repositories.
-
Data produced by such projects are not considered collaboration data, unless the producers decide to make it collaboration data and the executive committee is willing to maintain and/or host the data.
Any scientific research (with the expectation of producing one or more publications) that uses SXS resources (§7) is designated an SXS project subject to oversight by the SXS executive committee. Any project that uses only public data from the start of the project will not be designated an SXS project. When starting a new project, SXS members must consult with a member of the SXS executive committee (who may consult the entire executive committee and/or lead code developers) in order to determine whether or not their project is considered an SXS project. The executive committee may relinquish oversight of a project if the decision to do so is unanimous amongst the executive committee, in which case the project is not considered to be an SXS project.
At the initiation of an SXS project, an electronic announcement must be sent to the SXS Announce mailing list [email protected], announcing the project, summarizing the project and its scope in brief, listing those who are initially involved, and inviting other SXS members to join. The SXS Announce mailing list consists of all SXS members. Early and timely announcement of projects is vital to the health of the collaboration and to maintaining a collegial environment. Those leading the effort on the project are expected to provide periodic updates to an executive committee member and are strongly encouraged to present updates at one or more of the weekly telecons. Each project should outline the expectations of each contributor in order to earn authorship rights on publications from the project.
Although early project announcement is important, it is not intended as a method of “fencing off” scientific territory. SXS members are encouraged to collaborate and communicate with other interested members on analysis projects, and the participation of those wishing to join an analysis project should be welcomed assuming there is sufficient work to be done. At the same time, there may be cases in which multiple, independent analysis work on the same or similar topics is appropriate or even desirable. In these cases, the executive committee will be responsible for ensuring sufficient coordination of the analyses and resulting publications.
In order to achieve its scientific goals, the SXS collaboration provides a set of community resources for all SXS members. These include a set of SXS codes whose developers nay earn authorship rights on publications from a subset of SXS projects, and SXS infrastructure whose maintainers may also earn authorship rights as described below.
Codes developed to produce collaboration data must be made available to all SXS members. In order to recognize the significant work of code developers, the executive committee may designate a code as a SXS collaboration code which gives some of its developers authorship rights on a subset of SXS projects that either use the code or non-public data generated by the code. The lead developers of a code may submit a request to the executive committee that their code be designated as an SXS collaboration code. The executive committee may also promote codes developed within the collaboration to be a collaboration code so that there is someone to take them over in case the primary developer leaves academia. The executive committee, however, can not designate external codes to be SXS codes. In addition, the executive committee can demote an existing SXS code if it is no longer maintained.
Once designated as a collaboration code by the executive committee, the lead developers of the code must present and receive executive committee approval of a management plan that:
-
Explains how the code will be made accessible to all SXS members. For example, as either a public repository or a private repository in the GitHub sxs-collaboration organization.
-
Describes how the code is documented, and how SXS members can ask for help in using the code.
-
Describes how others can contribute to the code.
-
Designates one to three lead developers who will be the primary contacts for interaction with the executive committee, and for inquiries from SXS members. Note that a member of the executive committee is permitted be a lead developer.
-
Describes the publication policies for papers that use the code or non-public data produced by the code. We provide a default publication policy in §8.
Otherwise, developers are free to organize their project as they see fit. Developers are free to modify their publication policies, subject to approval from the executive committee.
Developers are expected to provide reasonable support for existing code, including improving documentation and fixing bugs on a reasonable timescale. Developers, however, are not required to implement new features, nor spend unreasonable time supporting new code development by others.
Note that simple codes and scripts will not be designated as collaboration codes. Only codes with significant development and maintenance will become collaboration codes. Please discuss with a member of the executive committee any development plans for any codes beyond simple plotting scripts and data analysis tools.
The advantages of being designated a code as a collaboration code are several:
-
Some developers of a collaboration code are given publication rights on projects that use the code or data produced by the code.
-
Additional SXS members can contribute to the code leading to significant improvements for all SXS members.
-
The collaboration will be able to ensure the existence of the code beyond the interests of the original developer.
Most SXS members will contribute to SXS codes in a modest fashion during work towards their projects. However, a small number of SXS members put in significant effort into building the infrastructure of a SXS code. In order to reward their effort, an SXS member can be designated to have earned authorship rights on papers using the SXS code. Each collaboration code should outline the requirements for someone being designated as having earned authorship rights. For large codes such as SpEC or SpECTRE, the suggestion is a total of approximately 3000 hours of effort. For large codes, authorship rights may be granted for a subset of the code.
In addition, an SXS member can be earn authorship rights for making a significant contribution to the code, as decided by the existing developers of the code. If the current developers do not deem the contribution significant enough to earn authorship rights, the SXS member may appeal to the executive committee. The executive committee will discuss the appeal with the current developers and, if they so choose, deem the contribution significant. The following all count as code infrastructure work:
-
Maintenance, refactoring, and modernization of source code, build systems, continuous integration, and source repositories
-
Fixing bugs and optimizing code
-
Performing code review
-
Adding or maintaining the ability to build the SXS code on high performance computing systems that SXS uses
-
Development and implementation of code that is merged into the SXS accessible repository, clearly documented, well-tested to ensure correctness over time, and align with the scientific goals of the collaboration.
-
Development of backend code that allows the algorithms to work together to perform simulations (e.g. parallelization code like MPI, I/O code, widely used data structures, etc.)
-
Running workshops about the code or concepts used by the code.
The list of developers with authorship rights for each code shall be maintained by the executive committee. Nominations for new authorship rights based on contributing development work shall be brought forward to the executive committee at the beginning of January, May, and September of each year. Approval of authorship rights shall be carried out by the executive committee with consultation of existing developers. Once given authorship rights, that status is maintained as long as the person remains a member or participant in the SXS collaboration.
The current list of SXS codes and their lead developers are listed in Appendix 10.
The SXS collaboration provides a set of community resources for all members. These include:
-
SXS website https://www.black-holes.org
-
SXS waveform catalog
-
SXS GitHub organization https://github.com/sxs-collaboration
-
SXS Slack organization
-
SXS compute clusters
-
SXS continuous integration computers
-
SXS Google organization and mailing lists
-
SXS allocation on national computing clusters
-
Organization of workshops about SXS research
SXS members who spend time as maintainers of these resources can count the time towards earning authorship rights for the code of their choice, unless it is clearly contributing to a specific code. SXS members are encouraged to contribute to the maintenance of infrastructure, and should contact their local member of the executive committee in order to explore opportunities for how to contribute.
A complete list of SXS resources and their maintainers are listed in Appendix 11. If you believe there is an SXS resource missing from the list of resources, please contact a member of the executive committee in order to discuss if it should be included.
SXS views public outreach and engagement as an essential activity for SXS members to participate in. To this end, public outreach is counted as infrastructure work and is counted towards the time needed for earning authorship rights. The time can be allotted to any SXS project/code desired. Outreach activities include but are not limited to:
-
helping with science olympiads,
-
generating animations and videos for the SXS YouTube channel, or LIGO/LVK to use,
-
being a panelist at outreach events,
-
advocacy work related but not limited to mental health, diversity, equity, inclusion, accessibility, etc. in STEM/academia,
-
attending schools to teach children about science, even if it is not related to the SXS Scientific Goals,
-
running and helping with workshops for undergraduate or graduate students, for example as part of a Research Experience for Undergraduates program,
-
volunteering at science centers, science museums, or planetariums.
The SXS Publication Policy is designed to promote the scientific and technical accuracy and timeliness of SXS publications and to ensure that fair credit is given to the authors and to other individuals who have contributed to the resources used by a SXS project.
This policy covers all SXS projects unless modifications have been approved by the executive committee during the SXS project. The developers of each SXS code may choose to adopt these policies with respect to authorship rights for SXS projects that use the code or data produced by the code, including modifications approved by the executive committee. The policies apply to use of SXS codes, regardless of the copyright and license of the code, or whether or not the code is publicly available. It also applies to any data generated using a SXS code that were not public at the time the SXS Project began, even if those data become public before completion of the analysis and/or the resulting publication.
Disputes about publication matters, including but not limited to authorship and author ordering, will be referred to the executive committee if they cannot be resolved directly with the lead authors.
We distinguish several types of papers, which are governed by different guidelines, as discussed in later Sections of this policy:
-
Scientific publications presenting results using one or more SXS codes. These publications are further subdivided into:
-
Collaboration science papers that involve results highlighting major accomplishments for the core science goals of the SXS collaboration. For example, catalog papers, announcements of new waveforms, or highlights of major breakthroughs that SXS as a whole has achieved.
-
Standard science papers. Examples include surrogates built using private waveforms, efficacy of new types of initial data, efficacy of new gauge conditions, critical collapse, and simulations in beyond-GR theories.
-
-
Technical papers describing specific numerical algorithms. Technical papers do not show new scientific results, but may show some representative simulations compared to the existing methods. An example would be a paper describing local time stepping, demonstrating speedup and parallel scaling on various problems compared to the existing code.
It should be made clear what the scope of the project is from the beginning in order to decide the type of paper. If the scope significantly changes during the project, the executive committee must be updated and may deem the project to fall under a different paper category.
Authorship of SXS science publications using SXS codes will be drawn from two groups: (i) those members and external collaborators who contributed to the analysis and writing of the paper (referred to below as primary authors); and (ii) those designated developers for the SXS codes and maintainers of SXS resources used by the project.
For Collaboration science papers, the author list shall be The SXS Collaboration followed by the author names in alphabetical order. In general, anyone who is a member of SXS and has contributed to the results being presented has rights to authorship. This includes all designated developers of any SXS codes used to produce the results, as well as any designated maintainers of SXS infrastructure. Furthermore, someone who has run even a single simulation that is part of a catalog paper will be an author.
For standard science papers, the default ordering will include two tiers, the primary authors and analyzers, followed by an alphabetical listing of those SXS code developers with authorship rights who have requested authorship. The author ordering within the first tier is at the discretion of the lead authors of the paper. If they wish, the lead authors can opt for alphabetical ordering within the first tier or for alphabetical ordering of the entire list. An invitation to SXS code developers with authorship rights must be extended at least one week prior to writing of the initial draft in order to have the opportunity to meaningfully contribute to the paper. In addition, SXS code developers with authorship rights must be notified at least one week before submission of the paper so they have sufficient time to decide upon whether or not they wish to be an author on the paper. Please note the collaborative process is enhanced the earlier invitations are made.
For technical papers, authorship will generally be confined to those who made direct contributions to the paper, the lead authors shall decide on the author ordering. Again, they can choose to make the ordering alphabetical if they wish. In addition, the authors of such technical papers must be given authorship rights to at least the first three scientific applications of the methods or results of the technical paper.
The provisions of this authorship section may be superseded in cases of violation of the Code of Conduct.
-
Nils Deppe (Cornell University)
-
Matthew Duez (Washington State University)
-
Scott Field (University of Massachusetts Dartmouth)
-
Francois Foucart (University of New Hampshire)
-
Lawrence Kidder (Cornell University)
-
Geoffrey Lovelace (California State University, Fullerton)
-
Elias Most (California Institute of Technology)
-
Harald Pfeiffer (Max Planck Institute for Gravitational Physics)
-
Mark Scheel (California Institute of Technology)
-
Leo Stein (University of Mississippi)
-
Saul Teukolsky (California Institute of Technology and Cornell University)
-
Vijay Varma (University of Massachusetts Dartmouth)
-
Aaron Zimmerman (University of Texas)
-
Executive committee ([email protected]): Deppe, Duez, Foucart, Kidder, Lovelace, Most, Pfeiffer, Scheel, Stein, Teukolsky, Varma, Zimmerman
-
Ombudsperson ([email protected]): Geoffrey Lovelace
-
Student-Postdoc Advocate ([email protected]): Marceline (Marcie) Bonilla
A closed-source repository is available at https://github.com/sxs-collaboration/spec. This is only available to SXS members.
Please contact Larry Kidder, Mark Scheel, and Harald Pfeiffer for co-authorship on any papers using non-public data produced by SpEC.
A public repository is available at https://github.com/sxs-collaboration/spectre and website at https://spectre-code.org/.
Please see https://spectre-code.org/publication_policies.html for publication policies governing SpECTRE.
A public repository is available at https://github.com/sxs-collaboration/sxs, including documentation on how to obtain the package.
The following functionality does not require invitation for co-authorship:
-
sxs.load
-
sxs.simulations
-
metadata
-
horizons
The following functionality requires invitation for co-authorship for Mike Boyle for papers written by SXS members:
- sxs.julia, including the PN and GWFrames codes
A public repository is available at https://github.com/moble/PostNewtonian.jl, including documentation on how to obtain the package.
Offering co-authorship to Mike Boyle is required for papers written by SXS members.
Please use the sxs package (https://github.com/sxs-collaboration/sxs) to access the waveform catalog.
This can be queried from GitHub:
https://github.com/orgs/sxs-collaboration/people?query=role%3Aowner
Please see the Wiki,
https://github.com/sxs-collaboration/WelcomeToSXS/wiki/Slack
Please see the Wiki,
https://github.com/sxs-collaboration/WelcomeToSXS/wiki/Computing-Resources
Please see the Wiki,
https://github.com/sxs-collaboration/WelcomeToSXS/wiki/SXS-Mailing-Lists