xioxox

There's this paper which describes a simplified fluid dynamics appropriate for games: Real-Time Fluid Dynamics for Games by Jos Stam. You can find the paper and implementations by searching. It's based around numerical stability and speed, rather than accuracy. I think it would be interesting to put this into a simcity-like game to get good air pollution maps.

I'm not sure if this WebGL page is based around this algorithm.

What? Where is this good string support in Fortran 2003, 2008 and 2018? I must have missed it in the manual. Now you can allocate a string of a non fixed size - simply amazing technology! Actually, one of my compiler crashes was trying to use this revolutionary feature.

Although Fortran compilers may produce fast code (they have to - there's no chance to play with SIMD intrinsics or templates unless you want to use C++), I don't find them very good. I've personally hit several bugs in gfortran. The code I maintain now has some extremely ugly hacks to work around unfixed compiler bugs. I recently tried compiling it with Intel Fortran and got a compiler crash on one input file. Maybe they work well with Fortran 77 level code, but the Fortran 2003 level support seemed rather buggy. I suppose this is the problem with a minority language.

I won't recommend Fortran unless the code has to be written by scientists who know nothing else. It has horrible string support, no data structure or algorithm library (like STL), no templates, few non-numeric libraries (e.g. http, json...) and (as above) buggy compilers. Furthermore, C++ gives you much more control over numerical speed when you need it.

There's quite a lot of citations to problems fixed by high precision numbers here: https://www.mdpi.com/2227-7390/3/2/337/htm

There are quite a lot of these. Here is one I like: https://automeris.io/WebPlotDigitizer/

That's a relief considering how bad DAB is. Most stations in the UK are stuck on DAB rather than DAB+, which means poor MP2 codec quality. Then they've gone for more identikit stations rather than higher bitrates. There's very little above 128 kbps and I believe they use mono for some. Then you have the problems with signal dropout, where the sound doesn't degrade gracefully in poor signal areas. Poor battery life is also an issue. If it wasn't the sunk costs of people buying these receivers and the loss of face after all the years of propaganda by the authorities pushing the standard, it would have been dropped.

I'm not sure why you're bringing up synchrotron radiation in particular. Although it's important for some sources, it's not driving the majority of what is being seen here. Comptonization is important for active black holes. The radiation from the milky way has strong emission lines - it's not a synchrotron spectrum. Mostly thermal emission is emitted from clusters of galaxies. There are a lot of different emission processes to consider in astrophysics.

I believe it's detecting more sources than expected. This can be to do with how efficient observations are (very good so far), how low the background is (higher than expected, but stable), the performance of the telescope in space, and how good the simulations of the data are (we're still working on them!).

I was very impressed with the picture of the Shapley supercluster (see article), which is very overdense part of the local universe, containing dozens of clusters of galaxies, each of those with 100s to 1000s of galaxies. In addition, we took some performance verification observations at the start, and these were really nice: http://www.mpe.mpg.de/7362095/news20191022

The picture is a bit misleading about the number of sources. It's really dominated by our galaxy, as most sources are point-like. You cannot really see the majority of them individually in the full-sky map given its spatial resolution, particularly as we applied some smoothing to the data to help emphasise the galactic structure.

We're also going to get another 3.5 years more data in the survey, which is going to find a lot more sources.

Here's a nice video showing how SRG/eROSITA scans the sky: https://www.youtube.com/watch?v=z8M-80aMDO0

XMM is still extremely useful. There was a recent report that using clever techniques ESA are going to keep it going for another 10 years: https://www.esa.int/Enabling_Support/Operations/Teaching_an_...

XMM has a smaller field of view than eROSITA, but more light gathering capability (effective area), particularly at higher energies. It also has different types of instruments, such as the X-ray gratings.

eROSITA is really designed for doing surveys with its wide unobstructed field of view, and it will be doing just that for the next 3.5 yrs. We really need XMM to follow up in detail the most interesting sources we discover during the survey.

Some of the structure can be seen in the old ROSAT maps from the 90s: http://www.xray.mpe.mpg.de/rosat/survey/sxrb/12/ass.html

Recently XMM looked at the centre of the galaxy, finding chimney-like structures which may link to the bubbles. This is on a much smaller region, however: http://www.esa.int/Science_Exploration/Space_Science/Giant_c...

Nothing since ROSAT has had the ability to map large areas like eROSITA/SRG. ABRIXAS was supposed to be the successor to ROSAT, but it failed shortly after launch.

The half energy width (angle over which half the energy is deposited) is around 16 arcsec on the axis of the telescopes (3600 arcsec=1 deg). Due to the Wolter geometry, it gets worse as you go off-axis. In the survey sources scan over the field of view. The average survey performance is around 28 arcsec.

Lots! It has discovered about a million X-ray sources, about twice as many as previously known about. Most of these sources will be active galactic nuclei (supermassive black holes that are accreting material) in distant galaxies. There's still lots of work to do in characterising these objects though and understanding the population.

I'm a scientist on the team who did this (I actually helped put this picture together), so I can try to answer questions...

The eROSITA telescope onboard the SRG observatory has completed its first survey of the sky in X-rays, producing the deepest ever map in X-rays and finding over a million sources. Most of these sources are active black holes, clusters of galaxies, supernova remnants and stars.

Annotated and high res images can be found here: http://www.mpe.mpg.de/7461950/erass1-presskit

The UK has had sitcoms on the radio since the 50s and TV since the 60s, when there weren't many channels. I think it's more down to what the controllers of the channels want to put on it. Sitcoms can be extremely popular - Only Fools and Horses was watched by around 40% of the UK population at its peak.

Just a question - why do you have a dependency hell? You could restrict yourself to the Python standard library, and you would only have one dependency. The Python standard library is much nicer than bash if you need more complex data structures than what bash provides.

I guess that's a no then. Well, I better give up on Fortran if I need to load configuration files, sort data, expand an array, take command line parameters, associate some text with the data, or use a hash table, if those aren't reasonable features. Apparently, it's only acceptable to use fortran to load some matrix, process it, then spit something out into a file.

Most of the fortran codes I'm working on would be much simpler with a common libraries to do things like that.

Do they have libraries for JSON, network functions, strings, data types (e.g. dict/map, resizeable vector, sorting, linked list, kd-tree...), databases, and all the things that make a programming language useful? Please point me to the library. I'm only aware of numerics.

That might fix the compiler quality and vectorization, but it doesn't fix the lack of library and terrible string support.

Edit: plus to ship our code to others requires a free good quality compiler. In the C/C++ world, that is standard. In fortran, that is not the case.

We're writing it for the ground processing for data from a new space telescope. Personally, I wish I was writing C++ or Python, but it does allow scientists to start writing code much more easily than C/C++ does, though Python is now more familiar to younger scientists than Fortran. Python has the downside of a lack of stability, however.

Fortan is pretty painful to write in. The lack of an STL means writing algorithms yourself. There is no good set of libraries, so you have to write more stuff yourself.

The string support is horrendous. Most of the language is based around clumsy fixed size strings. I wish they would add a new flexible string type.

The compiler quality is not up to C++ standards. My code currently has some nasty workarounds for problems in gfortran. It's not good to keep discovering compiler bugs.

I also find it's much vaulted numerical capabilities overstated. Vectorization only works in simple cases. You can't drop down to using SIMD wrappers to fix this. It's nice to be able to pass arrays around more easily than C, however. A good C++ array library would be better, but that would require everyone to agree on one.

I understood that on Linux using a process was similar in speed to a thread, though they're much slower on Windows. Has that changed?

For my python multi core code I like using fork with sending objects over a socket with pickle. It gives more control than multiprocessing.

It works pretty well. One downside of fork with python is that the reference counters are scattered about, leading to big COW memory churn, however. Big numpy arrays should be shared, however.

Did I use the word "often" in my comment above? Anyway, as an astronomer, I've heard about lucky imaging quite a few times - it likely depends what other astronomers you are exposed to. Of course, it can currently only be used on some bright targets, but it's a fascinating method. Similar techniques are also now being used at other wavelengths, such as for the LOFAR low frequency radio telescope.

As I mentioned above, there is a technique called lucky imaging, where you take lots of short exposures and only use the best ones. In astronomy, this can be used to reach the diffraction limit. You need a bright source, however, and it provides a narrow field of view.

In astronomy a technique called lucky imaging can be used to reduce the effects of the atmosphere. You use a high frame rate and throw away all the frames where the atmospheric quality is poor. This technique produces a narrow field of view, however, and requires a lot of photons.

Have a look at the game Control. I think this is a game where I feel they've used the technology really well. Maybe the office building location is a good one for raytracing, as it's full of reflective surfaces, but the graphics feel substantially better with it switched on. Remedy Games also managed to maintain a reasonable framerate with lower end RTX hardware. Other games look less impressive, however, such as minor changes in the shadows. It obviously requires some thought before it can be used.

I have an RTX 2060. I was very impressed by the game Control. It uses raytacing and has good frame rates. It's graphics are really nice. It certainly looks possible to get good results with current hardware, particularly now DLSS 2 is as available.

x2go and xpra allow some lossy compression algorithms.

There's no supposedly for me using compression. I just checked - it consistently takes 3x longer to launch an xterm without compression than with compression (15 vs 45s!).

Everyone probably already knows this, but enabling compression (-C) makes running remote X programs more usable over slower connections.