mturk

This is a much better idea than the d216, and probably a lot more fun.

I really like the "funky dice" that get used in Dungeon Crawl Classics [1], like the D5 which shows up here. Also, it's probably worth noting that Lou Zocchi had at least four major iterations of the Zocchihedron (d100), with different braking mechanisms, and that they're basically impossible to obtain in the last couple years. He lost a fair bit of his work in a fire [2] and had some major health problems [3] last year as well.

As a sidenote, I'm not sure why a d216 hasn't ever been made -- that one feels like a fun (novelty) opportunity to replace 3d6 for attribute rolls.

[1]: https://goodman-games.com/dungeon-crawl-classics-rpg/

[2]: https://goodman-games.com/blog/2020/01/06/support-lou-zocchi...

[3]: https://goodman-games.com/blog/2021/09/24/send-lou-zocchi-a-...

Kaitai is a really great system, with an awesome WebIDE. At work we have just started a project to use it for astrophysics simulations and data from dark matter detectors, and one of my hobby projects is to use it to explore retro game data formats.

I grew up here. You could smell the tannery from miles away.

In sixth grade, we had a visit from a community member. I forget the nominal purpose, but it was in the sixth grade building which at the time was just down the street from WWW. I remember him saying to us, "Lots of people say the tannery smells terrible. I think it smells like money."

When generating cosmological initial conditions for use in simulations of large-scale structure, one common method is to utilize random numbers (distributed about a known power spectrum) in k-space and then transforming back to real space. Some details can be found here: https://enzo.readthedocs.io/en/enzo-2.3/_downloads/makeics.p...

I love Kaitai, and use it extensively (outside my day job) for exploring binary file formats of things like DOS games and quilting patterns. About a year ago I wrote a blog entry about using it for scientific data: https://matthewturk.github.io/post/kaitai-struct-scientific-... .

Recently I learned about some pretty cool work using it with respect to high-energy physics:

https://osf.io/2sner/

I have and like the gameshell from clockworkpi. I'm particularly intrigued by the "Volume VIZ" window on the stock image and curious if that's a real pic or a staged/rendered one.

The article suggests they will be able to "unambiguously identify" Population III stars, which would be absolutely incredible.

I believe it was made with Twine:

https://www.konbini.com/en/techandinnovation/twine-free-tool...

http://twinery.org/

Yup, and we don't use a rainbow colormap by default anymore! We do provide a few custom ones that were developed with viscm, which I believe was used by in development of viridis, magma, etc. I think the specific examples are all from the published literature, and we accepted them as submitted by users -- but a refresh would be good!

I opened an issue: https://github.com/yt-project/website/issues/70

I work on yt, and I just wanted to comment to say that whenever I stumble on a mention of it somewhere, I genuinely feel warm inside. Thank you for thinking of us!

One of the things we've tried to do -- especially by leveraging the technology and innovations in the tools we build on (especially matplotlib!) -- is to make it easier to make visualizations and plots that are "by-default" communicative and information-rich.

And, of course we have lots of room for improvement, for picking up and encouraging "best practices" at the library level, but it has been really enjoyable and illuminating to have the opportunity to explore that with the community.

This inspired a project I worked on with some collaborators a while back. DOI: http://dx.doi.org/10.5281/zenodo.10773 and code: https://pypi.python.org/pypi/thingking

We used it to enable analyzing trillion particle dark matter simulations a halo at a time, as though they were local. It was fun. We made it part of the way into implementing an fopencookie version, but ended up moving on to other projects.

Reading over the list of priorities in the PDF linked from the Whitehouse blog, the one that I was the most pleased about was improving HPC productivity.

No, not quite. It depends on if the library is pure python. If it is, then adding support for pip install is possible, but not implemented. If it's not pure python, it is a lot harder -- it has to be statically linked into the PNaCl executable, which sometimes requires a bit of patching the code. For example, to get pandas in, I had to modify how it included np_datetime, and to get HDF5 in I had to pre-generate how it managed endianness.

That being said, I've been working on making it easier for pure python importing, and one fun thing is that you can actually mount an HTTP/CORS-accessible endpoint as a file system and import that. I have done this with a pastebin; I turned on CORS, mounted it inside the NaCl kernel, and executed pastes.

At SciPy this year, Kester and I will be giving a talk on this: https://conference.scipy.org/scipy2014/schedule/presentation...

That's true for the GDrive integration. All of the python-in-PNaCl code is available already as part of naclports.

There is a strong, growing movement to improve scientific code. As two quick examples, the WSSSPE series: http://wssspe.researchcomputing.org.uk/ and the Software Sustainability Institute: http://software.ac.uk/ .

It depends on if you are counting hardware costs or software costs as well. The rough estimate I heard recently is that an hour of programmer time costs about the same as an hour of a 100 Teraflop computer.

I am an astrophysicist, and I deal with this issue directly. In my simulations, I do deeply nested Adaptive Mesh Refinement calculations. These simulations run inside an Eulerian grid, where each cell contains a fluid element. These cells are collected into grid patches. When a cell inside a given grid exceeds some criteria, we refine it by inserting 8 cells; the next level of cells are then collected and minimum bounding boxes are created that cover the flagged cells, and we compute now at an additional 'level' of refinement.

My research concerns the formation of the first stars in the universe. In order to set up the initial conditions of these objects correctly, we have to resolve fluctuations in the background density of the Universe on the scale of kiloparsecs. However, we are also mostly concerned about how the fluid behaves on much smaller scales, at the tens to hundreds to thousands of AU scale, all the way down to the radius of the sun or even lower.

In one of my "stunt" runs, I ran up to 42 levels of refinement inside a box; this means that the dynamic range between the coarsest cells and the finest cells was 2^42. For the most part, however, we only use about 30-33 levels of refinement. In order to attain this resolution, we utilize extended precision positioning. (Future versions of the code will utilize integer positioning with relative offsets for Lagrangian elements like particles.) Inserting this functionality into the code took quite a bit of debugging and testing, in particular because we had to account for differences in how Intel, PGI and GNU passed extended precision values back and forth between Fortran and C.

I have uploaded a very simple 2D zoomin movie of one of these simulations, which only had 30 levels of refinement, to Vimeo. It's busy converting as I write this, but it will be found here when it has completed: http://vimeo.com/23176123