yt-project / yt-4.0-paper Goto Github PK

Because we only have one top-level # section, our section numbering is all off. I think this could be fixed by adding some special handling to the way the markdown is converted to HTML for the title, or maybe not.

We need a diagram for volume rendering of grid cells. I've got one in progress.

Currently stubbed in content/50.halo_finding_and_catalogs.md

Currently stubbed in content/15.development_procedure.md

This is currently stubbed out in content/25.processing_and_analysis.md.

Currently stubbed in content/55.scaling_parallelism.md.

Merge content from analysis modules into ecosystem of packages.

The DOI for Amanatides & Woo 1987 is a bit strange!

On https://dblp.org/db/conf/eurographics/eg1987.html it's listed as 10.2312/egtp.19871000 , but this isn't registered with DOI.org, which throws:

https://doi.org/10.2312/egtp.19871000 .

Once we get this resolved, let's move to using it correctly.

Currently stubbed in content/35.viz_and_volrendering.md

The units section may already be complete, but this issue may serve as a place for further discussion. content/40.units_and_quantities.md

Sections in content/35.viz_and_volrendering.md need to be filled out.

I've been giving a fair bit of thought to the order of authorship on the paper. I personally reject the premise that authorship requires contribution of text, but, the there may be some validity in ordering the authors based on textual contributions.

I would really like to be the first author after "The yt project" but I'm not sure I can ethically justify special-casing for that. But, if I could, what I am leaning toward is a two-tier system. Those authors who have contributed text to the paper (including whose text has been committed to the repository by me, like @langmm ) would be in Tier One, and they would be in the first set of authors. The second set of authors would be those who are authors on the paper, but have not contributed substantial text to the paper.

My proposal would be to explore either randomizing or alphabetizing the second tier of authors, and potentially ordering the first by "amount of effort toward this specific paper." The issue I run into there is that I'm not sure we can really quantify or order in that tier. (It would, though, probably result in me getting my position toward the top.)

I'll include a link to this issue when I email to the co-author list, and solicit ideas and feedback.

In the "Indexing and Geometry" section, there's a beautiful D3 script that translates a logically-cartesian grid to a real-space one, but the connexions (appearing as the mouse hovers the cells) do not all make sense
Here's an example of a broken one

I'd fix this if I knew javascript + D3

The section on governance is stubbed out in content/10.community_building.md

Some text is available already in content/65.extensions.md

At present (and as noted by @cphyc in the section on octrees) we don't currently have any section describing derived fields.

As a follow-up to #21 , @langmm has given permission to incorporate her bitmap indices writeup in this paper. This text is here: https://github.com/data-exp-lab/bitmap_paper

I'll take this on.

Right now the octree figures are not the right size and they render with scrollbars. I wonder if we could either upsize them so that by default they have the right aspect ratio/width, or if we could make the caption flow around them. Or both!

Currently stubbed out in content/30.abstracting_simulation_types.md (I guess?)

In keeping with our inclusive and broad authorship policy, we should reach out to all potential authors. This will need to balance the concerns of inviting authorship without being annoying by sending unsolicited emails.

I believe the procedure should go something like:

• Draft the invitation email
• Construct comprehensive list of all contributors
• Send email, with instructions, and cutoff date of 30 days hence

Previously, we had required that individuals provide their own pull request to the repository. I am now wondering if we could automate this somewhat, possibly by having a form submission that issued pull requests.

Additionally, to avoid merge conflicts, I think that we should have this done in a staging area, wherein new authors are added to new files, then those are collected into a single yml. Right now it's too easy to get conflicts from appending authors to the authorlist.

Hi all, somehow my remotes in git got confused, and I have been pushing changes up here instead of to my fork.

I'm working on fixing that, but just for reference, the changesets I pushed without review:

027995a
8930bba
0cea417

The entire section "User friendliness" is currently empty and needs filling. Specfifically, this includes right now:

• Publication-quality plots
• Jupyter Integration

I will reference the widgyts paper in the latter, and discuss the choice of default values in the former.

I think there's also room for a section about the type hinting and error message improvements.

This figure should be included or scrapped!

https://observablehq.com/d/b1b70cc5cc1c921c

I'm willing to contribute text to any of the following sections:

• Governance
• Processing and Analysis of Data
• Halo-Finding and Catalogs
• Scaling and Parallelism
• Analysis Modules

In content/15.development_procedure.md we need some words about pre-commit.ci.

As noted by @chummels , the Cholla frontend needs to be added to the list. I'm assigning this to Cameron as I think he's the best point person.

As noted in #81 we should grab the stats during build, not manually.

I've drafted an authorship policy and included it in README.md. Discussion and suggestions for changes can go here.

Right now the pixelization section has good information, but needs a diagram. This should be quite straightforward to construct given the diagrams we already have, and shouldn't take long.

There's a comment about the cell f20 which I do not understand. @cphyc , there's a bit in this section that says:

NOTE: the blue cell should be used in the example

that I don't totally understand. Should I modify the diagrams?

I believe the best path forward is to make this paper about yt-4.0, as we are approaching the 4.0 release.

When upgrading to latest rootstock (#79) we lost the styling that helped with the YTEP table. This is just a placeholder so I remember to fix it up.

A venue for this paper should be identified. This poses a handful of challenges, but none of them are insurmountable.

1. The venue should allow for long author lists.
2. The venue should be supportive of software-ish papers. (This isn't exactly a software paper, but it is closer to that than anything else.)
3. Stretch goal: allow our interactive figures. I genuinely think this is unlikely, and that we will probably end up relying on the web deployment of the paper for these figures. (They all have fallbacks.)
4. Something thaqt is not necessarily explicitly tied to astrophysics.

Hello Manubot user.

If you were not already aware, your paper is being showcased in the Manubot Catalog.

Previously, we were making our own thumbnails for each paper, and hosting them in the same repository as manubot.org. But now we are moving to a system of having each paper store its thumbnail in its own repository, and linking to it from there.

Here is our suggested thumbnail for your paper that follows the new thumbnail guidelines:

Please place this image in the root of your repository with the name thumbnail.png. Once you have, let us know in this issue and we'll do the rest to update the catalog.

Need examples of scaling of operations.

I added a YTEP table, which I generated using https://gist.github.com/matthewturk/aa0235f5a63c23ff3eae84a9bf0719b8 . I wasn't able to figure out how to auto-parse the status without making things a lot more complicated, but I think it should be included in the table.

I've started on an unstructured mesh section, in 30. I'm leaving here some notes:

• Add diagrams of elements (similar to this)
• Provide example images from MOOSE_sample_data/mps_out.e that show both displacement and higher-order interpolation
• Write up shortcomings in approach (esp scalability)

I am happy to write text on a variety of different areas including:

Development Procedure
Processing and Analysis of Data
Visualization and Volume Rendering, specifically the software VR infrastructure
Extensions

Or any other area that I can contribute something.

The method for intra-element value calculation, based on the YAML-to-Cython pipeline, needs to be covered.

Putting this here as a note, but the two commit graphs should be combined and the selection parameter should be linked on the two date ranges.

I made an interactive viz of commit history a while back. I can't quite figure out how to include the javascript and also create a static SVG, but that seems like something manubot can probably do. So we should include this if it's possible.

Lots of the sections could be shortened by taking historical notes and putting them into an appendix.

The pixelization process is largely the same as it was in the first paper, but in the interest of comprehensiveness updates should be provided and the section should be updated.

A table of selector objects, along with whether they have fast/slow paths for different operations, would be good for 20.data_objects.md.

A brief couple sentences about yt-idv would go well in 35.viz_and_volrendering.md.

A flow of how the selection process happens (oct_visitors, recursive selection, etc) should be added to the selection section.

For three of the main types of data (AMR, unstructured, particle) we should have a simple ThreeJS visualization of the structure of a simple dataset. This would be a very straightforward addition to the paper and could largely be snagged from an export from widgyts.

I'd like to have octree as well, but tht poses some additional challenges.

The current content of content/40.units_and_quantities.md references YTArray and so forth, and does not mention or cite the unyt paper. This should be updated to cite that paper, change the references to YTArray to unyt_array and otherwise be double-checked.