% $Id: newsletter.tex,v 1.78 2025/09/05 16:16:09 brandenb Exp $
%\documentclass{article}
\documentclass[twocolumn]{article}
\setlength{\textwidth}{170mm}
\setlength{\oddsidemargin}{-7mm}
\setlength{\textheight}{220mm}
\setlength{\topmargin}{-8mm}
\newcommand{\yapjN}[4]{, ``#4,'' {\em Astrophys.\ J.\ }{\bf #2}, #3 (#1).}
\newcommand{\const}{{\rm const}  {}}
\def\half{{\textstyle{1\over2}}}

%\bibliographystyle{apalike}
\bibliographystyle{gGAF} %is checked in (say "make ln")
%\usepackage{bm,natbib,html,wrapfig,graphicx,multicol,color} %,etoollbox}  %setspace,tocloft}
\usepackage{bm,natbib,wrapfig,graphicx,multicol,color} %,etoollbox}  %setspace,tocloft}
\usepackage{hyperref}
\usepackage[anythingbreaks]{breakurl} %AB: is needed
\usepackage{xcolor, soul}
\usepackage{listings}
\usepackage{amssymb}
\usepackage{amsmath}

\graphicspath{{./fig/}{./png/}}
\thispagestyle{empty}
\input ../../jour_def
\newcommand{\Fig}[1]{Figure~\ref{#1}}
\newcommand{\Figs}[2]{Figures~\ref{#1} and \ref{#2}}
\def\red{\textcolor{red}}
\def\blue{\textcolor{blue}}
\newcommand{\yjourN}[5]{:~#1, ``#5,'' {\em #2} {\bf #3}, #4}
\newcommand{\bra}[1]{\langle #1\rangle}
\newcommand{\Eq}[1]{Eq.~(\ref{#1})}
\newcommand{\AAA}{\bm{A}}
\newcommand{\BB}{\bm{B}}
\newcommand{\kk}{\bm{k}}
\newcommand{\xx}{\bm{x}}
\newcommand{\ii}{{\rm i}}
\newcommand{\dd}{{\rm d} {}}
\newcommand{\nab}{{\bm{\nabla}}}
\newcommand{\Cou}{{\mbox{Cou}}}
\def\HM{H_{\rm M}}
\def\EM{E_{\rm M}}
\def\EEM{{\cal E}_{\rm M}}
\def\Pm{\mbox{\rm Pr}_{\rm M}}
\def\Rm{\mbox{\rm Re}_{\rm M}}
\def\Rey{\mbox{\rm Re}}
\def\urms{u_{\rm rms}}
\def\kf{k_{\rm f}}
\newcommand{\Sec}[1]{Sect.~\ref{#1}}

\title{The {\sc Pencil Code} Newsletter}
\author{Issue 2025/1}
%\date{\today,~ $ $Revision: 1.78 $ $}
\date{September 5, 2025,~ $ $Revision: 1.78 $ $}
\begin{document}
\maketitle

\renewcommand{\baselinestretch}{-.4}\normalsize
\tableofcontents
\renewcommand{\baselinestretch}{1}\normalsize

\section{A new steering committee}

Since Friday 23 May 2025, the \textsc{Pencil Code} has a new steering
committee (PCSC).
As on previous occasions, Matthias Rheinhardt set up the adoodle to
perform the anonymous election.
Clara Dehman from the University of Alicante acted as an independent
observer.
Here her abbreviated statement from 23 May:

\textit{
I hereby confirm, in my role as observer, that the election for the PCSC has been successfully concluded.
Below is a detailed summary of the participation and the results.
A total of 33 individuals were eligible to vote. Of these, 17 submitted their ballots, resulting in a participation rate of 51.5\%.
One additional participant accessed the voting page but did not cast a vote, and is therefore considered an attentive non-voter (3.03\%).
The remaining 15 individuals (45.5\%) neither accessed the voting page nor submitted a vote and are thus classified as inattentive voters.
}

\vspace{2pt}
\noindent\textit{
The top five candidates in terms of support were:
\vspace{-4pt}
\begin{itemize}\itemsep-6pt
\item[-] Axel Brandenburg: 15 votes
\item[-] Philippe Bourdin: 12 votes
\item[-] Matthias Rheinhardt: 11 votes
\item[-] Jennifer Schober: 9 votes
\item[-] Piyali Chatterjee: 8 votes
\end{itemize}
\vspace{-4pt}
A total of 21 additional votes went to 5 more candidates.
With these results, we now have the newly elected members of the PCSC.
}

\vspace{-8pt}
\hfill\textit{Yours sincerely,}

\hfill\textit{Clara Dehman}
\vspace{15pt}

We wish the new committee good luck with their work.
A presentation of most of the candidates was published in issue 2023/3 of our newsletter.
The terms of reference of the PCSC are 
\url{https://norlx65.nordita.org/~brandenb/pencil-code/PCSC/ToR.pdf}.
We thank Nils E.\ Haugen, who has now been replaced by Jennifer Schober, for his work on the previous committee.

\section{Five years newsletter}

The first \textsc{Pencil Code} Newsletter was published
on 17 July 2020, over 5 years ago.
We are now in the sixth year and it is time to reflect on its usefulness.

\subsection{Request for feedback}

We are always interested in feedback from the community.
Here, we particularly ask the readers to give us feedback
about the Pencil Code Newsletter.

\subsection{The stated goal}

The stated goal back then was to update and remind the user community of
important results and developments.
In Newsletter 2020/2, we said
\\
\textit{
The {\sc Pencil Code} comes with a lot of default settings.
Many of the input parameters are set to what was of interest when
a particular module was developed.
Likewise, many logicals (switches) are set to whatever a particular
person considered useful at that time and what is imposed by the
constraint of backward compatibility.
Changing this all of a sudden could make others quite upset.
To raise awareness of changes that are considered justified,
we use the opportunity to highlight changes of defaults in the
Newsletter.}

\subsection{This newsletter}

This newsletter is exceptionally long -- partially because the previous
one was almost 9 months ago.
But this time we have also lots of contributions from the community.
Here, we discuss a default change \textit{proposed} by Fred Gent.
Regarding the GPU readiness of the code, we mainly refer to
issue 2024/2 of the newsletter.
A related point was the merge from the development branch
\texttt{gputestv6} to the main ({\tt master}) branch in March.

In this newsletter, we begin by reporting on the aforementioned
proposed default change.
We then present contributions that we have
received about the \textsc{Pencil Code} philosophy.
We also present some views of present and past PCSC members
and end with a description of other code changes and enhancements.

The full names and affiliations of the authors are written at the
beginning of each contribution.
In addition, to highlight that the articles reflect the view of
individuals and not of the PCSC, we also add the author's initials
to each of the following section titles:
\begin{tabular}{rl}
FAG: & Frederick A.\ Gent \\
SS: & Sankalp Srivastava \\
WD: & Wolfgang Dobler \\
EN: & Evangelia Ntormousi \\
GK: & G.\ Kishore \\
CCY: & Chao-Chin Yang \\
DC: & Daniel Carrera \\
\end{tabular}

We should also note that Kishore has started editing:
\url{license/contributor_guidelines.md}.
Comments on this are also welcome.

\section{Correction for mass diffusion}

\subsection{FAG: A proposed default change}

\noindent\textit{by Frederick Gent, Aalto University, Finland}
\texttt{<frederick.gent@aalto.fi>}\\
{\scriptsize received 24 April 2025}\\

\input fred

\subsection{SS: An alternate implementation of mass diffusion correction for the energy equation}

\noindent\textit{by Sankalp Srivastava, Indian Institute of Astrophysics, India}
\texttt{<sankalp.srivastava@iiap.res.in>}\\
{\scriptsize received 23 June 2025}\\

\vspace{-5mm}

\input Mass_diffusion

\section{Pencil Code Philosophy}

On March 6, 2025, Fred Gent alerted all users of the pending merge
of the gputestv6 branch back to the main one.
In his email with the subject line ``Pencil Code -- Astaroth pending merge - Urgent notice for action''
he wrote to \texttt{<pencil-code-discuss@googlegroups.com>},

\textit{
We plan to merge the gputestv6 branch into the master by mid March. The merger locally from master to gputestv6 and then from the merged gputestv6 back into the master has been successful, in the respect that all 69 of the standard auto-test samples are successful.}
\textit{
... However, there are many structural changes to many modules that are required to make possible the offloading of the PDE calculations to the GPUs. The changes should not interfere with the smooth application of the CPU standalone code, but reverting local changes to the GPU-ready code could potentially damage its operation.}

\textit{
Therefore, if you have any substantial changes locally, please let me know if you will be pushing them soon. It would likely be easier for us to merge your changes of the master branch into our gputestv6 branch before completing the merger into the master. In any case please complete your pushes by next week, so that we can complete the merger by mid-March.}

\textit{
If nobody has any significant changes then we would proceed promptly with the merger, after which users would need to pull the GPU-ready version before publishing local changes.}

In the wake of this major change, \textbf{but unrelated to it}, some potential
weaknesses of the hand\-ling of the code have been exposed.
This led to various discussions about the ``Pencil Code philosophy''.
To have a more detailed account of the different view points, we
solicited contributions to this newsletter; see the email to
\url{https://groups.google.com/g/pencil-code-discuss} on May 12.

\section{WD: Branches}

\noindent\textit{by Wolfgang Dobler, Berlin, Germany}
\texttt{<wdobler@posteo.de>}\\
{\scriptsize received 20 May 2025}

\input branches

\section{GK: Contributor guidelines and tagging}
\label{GKtagging}

\noindent\textit{by G.\ Kishore, Inter-University Centre for Astronomy \& Astrophysics, Pune, India}
\texttt{<kishore96@gmail.com>}\\
{\scriptsize received 23 May 2025}\\

\vspace{-5mm}

\input Kishore

\input Kishore2

\section{CCY: Any commit or merger should be rejected back to the committer if it does not pass the auto-tests}

\noindent\textit{by Chao-Chin Yang, The University of Alabama, Tuscaloosa, USA}
\texttt{<ccyang@ua.edu>}\\
{\scriptsize received 4 June 2025}\\

The previous suggestion that ``any commit that breaks the autotest can be reverted by anyone.''
still puts pressure on the maintainer.
This is the reason a pull request (PR) is better than the current approach: the merger has time to run the auto-tests before merging.

It was pointed out that we already have that in the Travis test.
The Travis could be set up to automatically start auto-tests for each commit coming in, so one could also set up a hook to reject for failed commit.

\paragraph{Further:}
\begin{itemize}
\item[(1)] If no branching is still favorable, any commit that breaks any auto-test should be immediately rejected;
if branching is the adopted way to go, any merger needs to pass all auto-tests before merging into main.
\item[(2)] No sample can be modified except by the maintainer.
Any people interested in changing a sample must collaborate with the maintainer before any commit can be made.
If the maintainer of a sample has clearly left the code or is not accountable for maintaining the sample, we need to find a replacement maintainer.
If no replacement can be found, we may want to remove the sample or move it to an obsolete folder. 
\end{itemize}

\section{DC: It would be good if Pencil were to adopt PRs and branches}

\noindent\textit{by Daniel Carrera, Iowa State University, Ames, USA}
\texttt{<dcarrera@gmail.com>}\\
{\scriptsize received 4 June 2025}\\
\vspace{-3mm}

\begin{itemize}
\item[(1)] Someone wants to propose a feature for Pencil.
They clone the git repository, add the feature, and when it's all tested they go to GitHub and create a pull request.
Then someone in charge at Pencil can approve or reject the PR.
\item[(2)] Branches give people freedom to make changes that temporarily break the code, as all their work is done in an isolated branch.
But when they finish coding the feature, they have to make sure that all tests pass before they can merge.
\end{itemize}
Point \#1 is code review, that’s how codes like Athena operate.
In the software industry code review is done every day.
However, I understand it would put too much pressure on the developer team, in essence it means that a set of eyes would be necessary to approve any commit.
The automated auto-test to reject commits that fail could be a compromise. 

I would add that another argument for branches and pull requests is to use the capabilities of git and github, which have become the standard in software development.
As it is, students that use and develop Pencil are not being trained in the new version control paradigm, but in the old one of svn and cvs.
That's the fundamental problem of education: we teach today, with the tools of yesterday, the people of tomorrow.
Wearing our educator hat, we should strive to teach a transferable skill, as many of our students will go on to become data scientists or software engineers;
while it is not our job to be a training ground for industry, it is a shortcoming if we don't equip them for that possibility.
And for what? Just so we don’t leave our comfort zone and learn something new ourselves?

\section{EN: Collaboration \& Reproducibility}

\noindent\textit{by Evangelia Ntormousi, Scuola Normale Superiore, Pisa, Italy}
\texttt{<evangelia.ntormousi@sns.it>}\\
{\scriptsize received 23 May 2025}\\

\input eva

\section{Individual views from PCSC members}

The following are, again, views of individual present and former
members of the PCSC and do not reflect a view of the PCSC itself.
\newline

\noindent\textit{by Nils E. L. Haugen, SINTEF, Trondheim}
\texttt{<Nils.E.Haugen@sintef.no>}\\

The Pencil Code is a versatile and flexible code that is continuously developed by a number of developers working on highly different physics. It is therefore important to facilitate:
\begin{itemize}
\item[a)] workflows that allow for efficient and flexible implementation of new code features, while
\item[b)] avoiding the code from branching out into multiple incompatible versions
\end{itemize}
At the same time, this should be achieved while avoiding:

\begin{itemize}
\item[1)] new errors being introduced to the code, and
\item[2)] that changes to the code make existing runs (not only the official samples) produce different results than previously. (This could for example be caused by the change of default values.)
\end{itemize}

In order to facilitate a) and b) while avoiding 1) and 2), I proposed the following four improvements to the Pencil Code check-in culture (should be strictly enforced by the entire community):
\begin{itemize}
\item[i.] The author of a commit should always run full auto-test (with full debug options, signalling NaNs, etc) before any commit to the main branch (this includes even small commits)
\item[ii.] The author should always get approval from the maintainer of a sample before changing a samples reference data file. If the maintainer of the sample does not respond within a reasonable time, the problem should be brought to the PCSC.
\item[iii.] If a commit breaks a sample, anybody can simply just revert that commit (while notifying the author). It is of course beneficial if the faulty code could be corrected to make the sample pass the test instead, but this is not a requirement.
\item[iv.] Nobody should ever change the value of defaults (even when default values are later found to be unphysical). This is important in order to avoid that older runs suddenly start producing different results.
\end{itemize}

The above check-in culture is independent of which version control tool that is used (svn or git), and the choice between svn and git is therefore up to the individual user. The important thing is not which tool that is used, but that errors are not introduced to the code, and that a given check-in does not otherwise cause any problems for other users.
\newline

\noindent\textit{by Axel Brandenburg, Nordita, Stockholm}
\texttt{<brandenb@nordita.org>}\\

\paragraph{Freedom to individuals.}
A guiding principle of the \textsc{Pencil Code} was always to provide
as much freedom to individuals as possible.
The highly modular structure of the code helps in letting thematically
different developments coexist with minimal chance of collisions
or conflicts.
The code also allows for different working styles and different approaches
to coexist as long as they do not interfere with each other.
This is particularly true for allowing different check-in practices
using either \texttt{svn} or \texttt{git} to coexist.

\paragraph{Branches.}
Those who like to work with branches can do it and those who do
developments on the main branch can do it as long as their work does not
interfere with anybody else's work.
In my view, this has been working rather well.

\begin{figure*}[t]\begin{center}
\includegraphics[width=\textwidth]{jobid}
\end{center}\caption[]{
Output from the \texttt{data/jobid.dat} file showing the
job ID on the supercomputer, the svn version number,
and the compile date the executable (which may well be much
older than the current code version checked out on the computer).
}\label{jobid}\end{figure*}

A difficulty with branches is that, in the past, they were often not short lived,
even though there was always the clear intention to merge them with the main branch as soon as possible.
When the gputestv6 branch was merged into the main branch on 19 March 2025 at 10:02 in the morning,
a total of 365 files were changed, 259 of those in src alone, and 156 of those were f90 files.
I have not checked in detail what happened, but for those files that I did check, I could not say that the changes were straightforward.
If there was something that broke for somebody (which has not yet been the case!)
it would be difficult to say exactly what the mistake was.
This was only because we know that everything was carefully tested.

\paragraph{From development to production.}
The gputestv6 branch was an example with a clear beginning and a clear end, but in general,
the idea that some code development is ready and can then be merged into the main branch seems somewhat alien to me.
In the case of a recent paper \citep{2025arXiv250502885B}, we tried out an idea and then continued to iterate on it.
Some of our earliest runs did already have production quality and entered
this paper, but the code development process continued beyond this point.
Even when the paper is finally submitted, comments from the referees or
other colleagues may inspire changes to the code and 
make additional runs with the modified code necessary,
while some of the old runs would still be ok.
This development can finally be called ``ready'' when the paper is
published, but that is also possibly
the time when one is no longer working with
it, so any mistakes that may occur when making this final product ready
(and perhaps still more beautiful) will no longer be scrutinized as much
as it would when one was still working with it.
(This may not apply to everybody, but to me it does.)

\paragraph{Unfinished pieces.}
It is plausible that I stop and won't finish the job, because more exciting things came up.
I have also seen others leaving certain developments untouched without there being any paper.
Such developments can come in handy for  
someone needing it for their own work.
If such development was hidden or left on a branch, one would never have known about it.
Also, why would have anybody kept it up to a date while many other
changes occurred to the rest of the code if it wasn't on the main branch?
This is why the practice of making changes on the main branch has advantages.

An example is the development of a special relativity extension of
the hydro module, which was started in 2022, but is still not completely ready.
Nevertheless, the partially ready version has already been used by others
for their research.
Keeping things on the branch does not easily facilitate such type of
cross-fertilization.

\paragraph{Open science.}
We are all encouraged to conduct \textit{open} science.
Therefore, there is an advantage if everybody whom we expose publicly
to our concrete simulation results (in preprints or in talks) 
has a chance to verify the results.
The referee of our paper, for example, might want to verify certain
results without waiting for the next ``code release''.

Having full and easy access to the detailed revision history can be (and
has been) beneficial in exposing mistakes at an early stage.
Accidental mistakes are sometimes discovered only years later
\citep[see, for example,][who corrected one of my
mistakes]{2025ApJ...986..183K}, so it is good if those can easily be
traced back when code versions and the date of compilation was recorded
for each run.
This is currently the case when using \texttt{start\_run.csh}, which outputs a
\texttt{data/jobid.dat} file like is shown in \Fig{jobid}.

\paragraph{Autotests \& their sensitivity.}
There is no recipe in designing a good autotest.
Whenever there is an opportunity, one should verify that there are samples, which are
sensitive to particular aspects of the code, and, for that matter,
not sensitive to the numerical representation of extremely small numbers or to algorithm-dependent
representations of sums.
One should also not forget that we have in place some tests of spectra, averages, slice files, etc.
I can therefore only appeal to everybody to help making autotests as good
as possible.
This would entail changing existing ones, but one should leave some days
between that and any related changes to the code.

\paragraph{Private copy of test results.}
It is generally good that everybody runs the autotest also on their own computer.
It does take some time, and by the time you remember about your test, you may
no longer have the output on your screen.
It is therefore good to write the output to disk using, e.g.,
\begin{verbatim}
pc_auto-test --log-dir=<directory for logs>.
\end{verbatim}
If still something goes wrong, it would be useful to be sure that this
was not because of something you should have been able to see yourself and
that it is really because of different build and environment
settings compared with the autotests on our web page.
Again, such discrepancies should be used as an encouragement to improve
the tests.

\paragraph{Tagged as ``released''.}
Given that many of us are checking in modifications to the main branch,
a common criticism is that people may download a version that does not
even pass the autotest.
To mitigate this problem, Philippe has restored the old functionality
that worked between 2007 and 2015, when the code was on google-code
(\url{https://code.google.com/archive/p/pencil-code/}),
namely the automatic tagging;\footnote{Note that G.\ Kishore also commented
on automatic tagging in his contribution (\Sec{GKtagging}) to this newsletter.} see
\url{https://github.com/pencil-code/pencil-code/tags}.
Thus, cautious users can use this version.
You can also do developments on an earlier version.
Your changes will then be merged once you update to the latest version.
\newline

\noindent\textit{by Matthias Rheinhardt, Aalto University, Finland}
\texttt{<matthias.rheinhardt@aalto.fi>}\\
\begin{itemize}
\item The local working routines of individuals cannot effectively be standardized by the community, and I also think, should not.
          So, what is happening solely on a local Git repo is up to the individual developer, while experiences can of course be shared.
\item According to my personal experience, dealing with conflicts in Git is less convenient and safe, especially when it comes to merging branches.
         In addition, having to keep an overview over a big number of branches on several different platforms poses an additional stress factor.
         Hence, I hold that the use of branches should be restricted to the absolute necessary.
\item How to define it? Tentatively, I would say that pure addenda do not require branches as they can be safely encapsulated. Typical examples 
         are new modules or new conditional branches in existing modules. To protect undue curious users, we should yet think about a safe automatism 
         (say in the build process), which blocks the use of immature
         new features from the outset, except for their developers.
\item The other extreme are code changes ``all over the place", necessitated by profound code reorganization. An example was the adaptation of the diagnostics
         calculations to (optional) concurrency with the PDE integration (using OpenMP). Here, I would say working on a branch was mandatory.
\item Reference data are in a way the most sensitive part of the whole project. A change to them can only be pushed if it is absolutely clear, which code change has made it necessary.
         Admissible examples are plain code bugs and improper physics. Also, the data change must be approved by at least a second developer, and the maintainer of the affected
         sample(s) should be involved whenever possible.
\item  Defaults should also be handled with great conservativeness. Planned changes should first be announced on \url{https://groups.google.com/g/pencil-code-discuss} and the discussion should 
          be given sufficient time to come to terms. Ideally, the maintainers of the affected samples should in addition be addressed directly.
\item Pull requests and, accordingly, code reviewing are basically desirable, but I see no way to organize assignment/distribution of the related work fairly across the community.
          
\end{itemize}

\section{New auto-test infrastructure}

With the inauguration of a new server to replace the old {\tt norlx51} one at Nordita,
a new scheme of auto-testing is introduced. First, the previous hourly and daily tests
are now performed only if needed: Without new check-ins, the auto-tests will not be started,
which saves precious computing time on the new server. Second, the distribution of tests is now different.
Instead of running all tests up to a certain level for each test run, we now have three tests,
where each of them employs disjunct sets of samples, so no repetitions of the same samples.
Third, we now have three tests instead of the two old tests: one basic, one normal, and one extended test.
Fourth, disjunct auto-test sets are now allowed to run in parallel, which was not possible on the old server.

\begin{figure*}[t]\begin{center}
\includegraphics[width=\textwidth]{auto-test}
\end{center}\caption[]{
Example of some successful and some failing tests.
Others are still running or scheduled to run.
}\label{auto-test}\end{figure*}

The new ``basic'' test is exactly equivalent to the Travis check (test levels 0 and 1),
which means it would run every minute, if there are new check-ins.
Unlike the original Travis check, this basic test will always run until the end:
If there are additional new check-ins while a test is running, the test will first
complete and then start again to test the untested check-ins at the next minute.

The new ``normal'' test contains the remaining set that is equivalent to the old hourly test (level 2).
This additional test will always start at 15 minutes after the full hour.

In addition we have the ``extended'' test to implement the remaining tests necessary to complete the full set of samples that was previously performed only around midnight.
This extended set will start now hourly at 55 minutes after the full hour.

With this new and partly parallel test strategy, we are now performing checks similar to the Travis test every minute --- also as a backup infrastructure to the Travis-CI.
Additionally, those auto-tests that were previously performed only once per day, are now running each hour.

\section{Random tips}

\subsection{User-specific settings}

Sometimes one likes to make certain settings for all runs of one installation of the \textsf{Pencil Code}.
For that purpose, a mechanism was introduced at the Pencil Code User Meeting in Graz (2023).
A user may create a file {\tt utils/USER/global\_run.in}' inside the main {\tt PENCIL\_HOME} directory.
This file will always be read before the {\tt run.in} file, so that all parameters defined in the
global file, are the new default values. After that, the definitions in the local {\tt run.in}
file are read and, if present, will supersede the global default run parameters.

To use this functionality, one only needs to set the environment variable {\tt PENCIL\_USER} to
contain exactly the {\tt USER} name, in which directory to look for the {\tt global\_run.in} file,
see above. If this environment variable is not present (or the path is wrong), only the local
parameters of the {\tt run.in} file will be read.

In case a user wants to give different global run parameter definitions, one can provide multiple
file names in the scheme {\tt utils/USER/HOST\_global\_run.in}. To select one of them to be used,
one needs to set another environment variable {\tt PENCIL\_HOST}  that contains the {\tt HOST} part.

\subsection{Safer snapshots}
Through setting {\tt lbackup\_snap=T} in {\tt run\_pars} the code is caused to hold the penultimate instance of {\tt var.dat} as {\tt var.dat.bck}. By this,  a failing write of {\tt var.dat} due to, e.g., 
job canceling or disk failure, would result merely in a loss of {\tt isave} integration timesteps. By default, this feature is at present off, but we may decide to change this in the future.

\subsection{Indicator file for snapshot writing}
During writing of {\tt var.dat}, {\tt VAR*}, {\tt dvar.dat}, or {\tt crash.dat}, the (empty) file {\tt WRITING} is now present in the working directory.

\subsection{Automatic CVS updates}
Setting {\tt lupdate\_cvs=T} in {\tt run\_pars} makes the code executing {\tt cvs ci} after each update of the time series. Default is ``{\tt F}".
Of course, this is only effective if {\tt pc\_cvsci} (or something equivalent) has been executed in this directory before.

\subsection{Check-in notifications}

Check-in notifications are currently not being sent out because the Google group mailing list does not forward emails from {\tt notifications@github.com}, even though GitHub support checked that emails are delivered there and are reaching Google groups.

\section{PC User Meeting \& School}

The next PC User Meeting will be held in Geneva/Switzerland.
Alberto Roper Pol organizes the meeting and has now opened the
registration on \url{https://indico.cern.ch/e/PCUM2025}.
The actual meeting will be preceded by \textsc{Pencil Code} School
on early Universe physics and gravitational waves (Oct 20-24).
The topic include Introduction to Pencil Code,
Finite-difference schemes for partial differential equations,
Post-processing of data with IDL and Python, and
GPU acceleration of Pencil Code,
as well as applications to particular physics cases with hands-on exercises on:
Magnetohydrodynamics of the early Universe
Generation and evolution of primordial magnetic fields,
Chiral magnetohydrodynamics,
First-order phase transitions,
Gravitational wave production, and
Axion inflation.
Registration is open and will close on July 31st. The school is limited to a maximum of 30 participants.
Participants of the school are encouraged to also participate in the user meeting (Oct 27-31) and need to register separately!

The lecturers include
Axel Brandenburg (Nordita),
Philippe Bourdin (University of Graz),
Simon Candelaresi (University of Augsburg),
Deepen Garg (University of Bonn),
Frederick Gent (Aalto University \& Nordita),
Matthias Rheinhardt (Aalto University),
Alberto Roper Pol (University of Geneva), and
Isak Stomberg (IFIC, Valencia).

Readers may also want to consult earlier teaching material on:
\url{https://www.youtube.com/watch?v=ncdLaTDkjKo} and
\url{https://jennifer-schober.com/teaching/pcum2024}.

\section{Upcoming meetings}

The \textit{Nordita Winter School -- Cosmological Magnetic Fields: Generation, Observation, and Modeling}
(\url{https://indico.fysik.su.se/event/8554/}) may be of interest to
students and young postdocs among the \textsc{Pencil Code} users,
because it contains hands-on exercises with the code.
The deadline for applications is \textit{15 October 2025}.
The event goes over 2 weeks: 12--23 January 2026.

\section{Papers since October 2024}

As usual, we look here at new papers that make use of the {\sc Pencil Code}.
Since the last newsletter of October 2024, 15 new papers have appeared    
on the arXiv, plus 33 others, some of which had been just preprints and  now have been published in a journal.
We list both here, altogether 48.
A browsable ADS list of all {\sc Pencil Code} papers can be found on:
\url{https://ui.adsabs.harvard.edu/public-libraries/iGR7N570Sy6AlhDMQRTe_A}.
If something is missing in those entries, you can also include it yourself in:
\url{https://github.com/pencil-code/pencil-code/blob/master/doc/citations/ref.bib},
or otherwise just email brandenb@nordita.org.
A compiled version of this file is available as
\url{https://github.com/pencil-code/website/blob/master/doc/citations.pdf},
where we also list a total of now 136 code comparison papers in the last
section ``Code comparison \& reference''.
Those are not included in our list below, nor among the now total number
of 722 research papers that use the {\sc Pencil Code}.

\nocite{
BB24,
2025MNRAS.542..884K,%Koshikumo+ "Magnetic flux transport via reconnection diffusion in different sonic regimes of interstellar MHD turbulence"
2025arXiv250610435G,%Godines+ "On the Mass Budget Problem of Protoplanetary Disks: Streaming Instability and Optically Thick Emission"
2025ApJ...989...39S,%Srivastava+ "The Relation between Solar Spicules and Magnetohydrodynamic Shocks"
2025arXiv250620538I,%Iarygina+ "Schwinger effect in axion inflation on a lattice"
2025A&A...699A.250H,%Hidalgo+ "Shaping core dynamos in A-type stars: The role of dipolar fossil fields"
2024A&A...691A.326H,%Hidalgo+ "Magnetohydrodynamic simulations of A-type stars: Long-term evolution of core dynamo cycles"
2025PhFl...37g5107S,%Sabelnikov+ "A priori assessment of gradient models of joint cumulants for large eddy simulations of premixed turbulent flames"
2025ApJ...979L..39T,%Tschernitz+Bourdin "Granulation and Convectional Driving on Stellar Surfaces"
2025JPlPh..91E..35H,%Hosking+ "Metastability of stratified magnetohydrostatic equilibria and their relaxation"
2025CoFl..27313903Y,%Yuvraj+ "How ``mixing'' affects propagation and structure of intensely turbulent, lean, hydrogen-air premixed flames"
2025arXiv250217178K,%Kishore+Singh "Rotational effects on the small-scale dynamo"
2025ApJ...986..183K,%Kishore+Singh "The spectra of solar magnetic energy and helicity"
2025A&A...696A..93W,%Warnecke+ "Small-scale and large-scale dynamos in global convection simulations of solar-like stars"
2025ApJ...983..105B,%Brandenburg+Scannapieco "Magnetically Assisted Vorticity Production in Decaying Acoustic Turbulence"
2025A&A...698L..13K,%Kapyla "Simulations of entropy rain-driven convection"
2025arXiv250416849B,%Brandenburg "Magnetorotational instability in a solar mean-field dynamo"
2025ApJ...984...78B,%Brandenburg+Vishniac "Magnetic helicity fluxes in dynamos from rotating inhomogeneous turbulence"
2025ApJ...984..113S,%Singh+Arunima "Reversals of toroidal magnetic field in local shearing box simulations of accretion disc with a hot corona"
2025ApJ...985...18R,%Rogachevskii+ "Theory of the Kinetic Helicity Effect on Turbulent Diffusion of Magnetic and Scalar Fields"
2025ApJ...984...88B,%Brandenburg+ "Helicity Effect on Turbulent Passive and Active Scalar Diffusivities"
2025JCAP...05..079S,%Sharma+ "Lattice simulations of axion-U(1) inflation: gravitational waves, magnetic fields, and black holes"
2025A&A...693A..89P,%Pandey+Bourdin "Investigating numerical stability by scaling heat conduction in a 1D hydrodynamic model of the solar atmosphere"
2025arXiv250502885B,%Brandenburg+Ntormousi "Magnetic field amplification during a turbulent collapse"
2025arXiv250503660M,%Mondal+ "Understanding large-scale dynamos in unstratified rotating shear flows"
2025MNRAS.541.3427S,%Shchutskyi+ "Kinematic dynamos and resolution limits for Smoothed Particle Magnetohydrodynamics"
2025MNRAS.539.3421R,%Rice+ "Dust density enhancements and the direct formation of planetary cores in gravitationally unstable discs"
2025MNRAS.540..532Q,%Qazi "Non-linear magnetic buoyancy instability and galactic dynamos"
2024AGUFMSH13B2928M,%Maity+ "On the Evolution of Reconnection Flux in Erupting Magnetic Flux Ropes: Insights from Observations and MHD Simulation"
2025AAS...24540206M,%Meftah "Hydrodynamic simulations of multiple low-mass migrating black holes in AGN disks"
2025PhRvD.111b3021P,%Park "Effect of turbulent kinetic helicity on diffusive beta effect for large scale dynamo"
2025arXiv250105732R,%Roper Pol+Salvino Midiri "Relativistic magnetohydrodynamics in the early Universe"
2025JPlPh..91E.113B,%Brandenburg+Yi+Wu "Inverse cascade from helical and nonhelical decaying columnar magnetic fields"
2025A&A...694A..39D,%Dehman+Brandenburg "Reality of Inverse Cascading in Neutron Star Crusts"
%2025arXiv250103876S,%Sharma+ "Computational Astrophysics, Data Science \& AI/ML in Astronomy: A Perspective from Indian Community"
2024JCAP...12..057B,%Brandenburg+ "Magnetogenesis from axion-SU(2) inflation"
2024ApJ...977..128M,%Mtchedlidze+ "Intergalactic medium rotation measure of primordial magnetic fields"
2025MNRAS.537L..26E,%Eriksson+ "Particle fragmentation inside planet-induced spiral waves"
2025MNRAS.536.1625S,%Shi+ "Kinetic field theory applied to planetesimal formation I: freely streaming dust particles"
2024arXiv241014497S,%Singh+Arunima "Reversals of toroidal magnetic field in local shearing box simulations of accretion disc with a hot corona"
2025PhRvD.111d3541V,%Vachaspati+Brandenburg "Spectra of magnetic fields from electroweak symmetry breaking"
2024arXiv241112953Z,%Zhou+Lai "Understanding the UV/Optical Variability of AGNs through Quasi-Periodic Large-scale Magnetic Dynamos"
2024PhFl...36k5152L,%Lipatnikov "A priori assessment of a simple approach to evaluating burning rate in large eddy simulations of premixed turbulent combustion"
2024ApJ...975..251V,%Vemareddy "Simulating the formation and eruption of flux rope by magneto-friction model driven by time-dependent electric fields"
2024A&A...691A.258S,%Schafer+ "Thousands of planetesimals: Simulating the streaming instability in very large computational domains"
2024A&A...690A..77E,%Elias-Lopez+ "Vorticity and magnetic dynamo from subsonic expansion waves II: Dependence on magnetic Prandtl number, forcing scale, cooling time"
2024OJAp....7E..75D,%Dwivedi+ "Quasi-two-dimensionality of three-dimensional, magnetically dominated, decaying turbulence"
2024ApJ...973...49K,%Kesri+ "Dependence of spicule properties on magnetic field -- results from Magnetohydrodynamics simulations"
2024GMS...283..179C%Candelaresi+Del Sordo "Stability of plasmas through magnetic helicity"
%
%2024arXiv240115860Z,%Zhou+Jingade "Correlation times of velocity and kinetic helicity fluctuations in nonhelical hydrodynamic turbulence"
%2024arXiv240416096D,%Dey+ "Spinning solar jets explained through the interplay between plasma sheets and vortex columns"
%
% outdated
%2023arXiv231109082K,%Kapyla "Effects of rotation and surface forcing on deep stellar convection zones"
%2023arXiv230705490Z,%Zhu+Shi "Helical and nonhelical (magneto-)Burgers turbulence: I. Compressibility reduction and beyond"
%2023arXiv230300911Y,%Yuvraj "On flame speed enhancement in turbulent premixed hydrogen-air flames during local flame-flame interaction"
%2022arXiv220606566M,%Masada+Sano "Rotational Dependence of Large-scale Dynamo in Strongly-stratified Convection: What Causes It?"
%2022arXiv220509261R,%Roper Pol "Gravitational waves from MHD turbulence at the QCD phase transition as a source for Pulsar Timing Arrays"
%2021arXiv210508287R,%Roper Pol "Gravitational radiation from MHD turbulence in the early universe"
}

\bibliography{ref}
\vspace{5mm}
\hrule
\vspace{2mm}
This {\sc Pencil Code} Newsletter was edited by
Axel Brandenburg {\tt <brandenb@nordita.org>}, Nordita, KTH Royal Institute of Technology and Stockholm University, SE-10691 Stockholm, Sweden;
and Matthias Rheinhardt {\tt <matthias.rheinhardt@aalto.fi>}, Department of Computer Science, Aalto University, PO Box 15400, FI-00076 Aalto, Finland.
See \url{http://www.nordita.org/~brandenb/pencil-code/newsletter} or
\url{https://github.com/pencil-code/website/tree/master/NewsLetters}
for the online version as well as back issues.

\end{document}
