GD
Geodynamics

Wit & Wisdom

Dancing on a volcano – the unspoken scientific endeavour

Dancing on a volcano – the unspoken scientific endeavour

Doing science is not a walk in the park. In fact, it might be closer to dancing on a volcano. Dan Bower, CSH and Ambizione Fellow at the University of Bern, Switzerland, takes full advantage of the creative freedom of a blog post to reiterate that scientific progress is not a straight-forward endeavour.

We all learn early in our education about the scientific method—the scientific approach to discern a new truth of nature by establishing a hypothesis that is then rigorously tested. Clearly this approach has been influential in establishing our wealth of knowledge to date, but it typically does not represent accurately the day-to-day reality of being a practitioner of science. This is because the scientific method implies a linear trajectory from proposing a hypothesis to sequential testing of the hypothesis until we naturally arrive at a conclusion that is a new result, hence providing a contribution to the knowledge database of humanity. It suggests we step through each stage of the method and necessarily arrive at a useful result, but unfortunately, this masks the reality of the daily lives of scientists.

In fact, as scientists our daily life often involves scrambling around on the side of a cantankerous volcano a few minutes before sunset; we have some understanding of where we came from and how we ended up here, but working at the edge of human knowledge is a challenging and unforgiving place. We took wrong steps enroute—some of which might actually turn out to be right steps in retrospect, but in relation to a completely different topic or problem than what we are working on. Rather than dancing elegantly through the different steps of the scientific method, we are instead struggling to see the ground below in the ever-darkening light, often dangling a foot into the unknown to see if we can gain some traction. Depending on your personality type and upcoming deadline schedule, this unknown can be the most invigorating or most stressful place to be in the uncharted landscape of modern science.

We glance at an incomplete map of the terrain to see if the discoveries of our scientific forefathers can cast new light on our scientific objective. We began the excursion optimistically with the goal of reaching the volcano’s crater, but after revising our project description and goals several times, we are now content with the view half-way up the mountain. It’s taken us longer than we thought to reach this point—but with an upcoming conference in a few weeks—we must set up camp, collect some data, and glean a new insight that no other soul on the rest of the planet has previously managed—either now or in the previous several centuries of modern science. The thought of that makes us a little nervous, not least because we now realise that the tools we brought with us are not up to the task following several breakages. There are new tools, but they have only just been delivered to base camp and will not be available for the rest of our project—we also need to obtain permission from an ex-collaborator (now turned competitor) to use them. We instead think of creative solutions to deal with this “challenge” (word of the expedition leader, I’d personally use stronger phrasing). We now iterate relentlessly between models and data until we conjure a new discovery. Well, we are not sure if it is strictly a discovery, but no-one else seems to report it any papers (that we read). We now debate if this is because our “discovery” is mind-blowingly obvious.

A helicopter flies overhead and drops us a few supplies for the remainder of our mountain excursion—including a new paper just published last week on the topic of our research. We panic—is this exactly the same as what we are doing, or a little bit different? Do our results agree? For that matter, do we want the results to agree? We again revise the goals of the project to utilise the one extra data point we have acquired to maximise the impact of our work and thereby justify our study as “a useful contribution to the literature” (again, words of the expedition leader). The title of our paper changes for the thousandth time, and even I am no longer sure I understand what the study is about. As a parting gift, the helicopter pilot informs us that we are not on the volcano we thought we were on—apparently that is a few hundred kilometers in a different direction. How did we end up here again? Not to worry, we can tweak a couple of parameters and then apply our insights to the actual volcano we are standing on—assuming it is actually a volcano—has anyone checked? We now push an excursion to the other volcano to future work, which in reality, means that we hope someone else will do it (but not before we write up our study). In the end of year summary, we report complete success of the project to the funding agency, and request follow-up funding a month later.

Have you ever danced on a volcano? Tweet us your story on convoluted science projects @EGU_GD under the hashtag #DancingOnAVolcano



The featured image of this post is provided by Floor de Goede, a Dutch comic artist who penned the graphic novel ‘Dansen op the vulkaan’ (Dancing on the volcano). He also illustrated many children’s books and draws the semi-autobiographical daily comic ‘Do you know Flo?‘. You can follow Floor de Goede on instagram at @flodego for daily comics (also in English!).


Writing the Methods Section

Writing the Methods Section

An important part of science is to share your results in the form of papers. Perhaps, even more important is to make those results understandable and reproducible in the Methods section. This week, Adina E. Pusok, Postdoctoral Researcher at the Department of Earth Sciences, University of Oxford, shares some very helpful tips for writing the Methods in a concise, efficient, and complete way. Writing up the methods should be no trip to fantasy land!

Adina Pusok. Postdoctoral Researcher in the Department of Earth Sciences, University of Oxford, UK.

For my occasional contribution to the Geodynamics blog, I return with (what I think) another essential topic from The Starter Pack for Early Career Geodynamicists (see end of blog post): how to write the methods section in your thesis, report or publication. Or using the original title: “Writing up the methods should be no trip to fantasy land”. Don’t get me wrong, I love the fantasy genre, but out of an entire scientific manuscript that pushes the boundaries of knowledge (with additional implications and/or speculations), the methods section should be plain and simple, objective and logically described – “just as it is”.

The motivation for this post came some months ago when I was reviewing two articles within a short time interval from each other, and I felt that some of my comments repeated – incomplete methods sections, assumptions let to be inferred by the reader, and which ultimately made assessment of the results more difficult. But I also consider it is not ok to write harsh reviews back (for these reasons), since again, there is little formal training for Early Career Scientists (ECS) on how to write scientific papers. Moreover, even when there is such formal training on academic writing, it is often generalized for all scientific disciplines, ignoring some important field-specific elements. For example, a medical trial methods section will look different from an astrophysics methods section, and within Earth Sciences, the methods section for a laboratory experiment on deformation of olivine will contain different things compared to a systematic study of numerical simulations of subduction dynamics.

A common approach by most students (especially first time) is to dump everything on paper and then hope it represents a complete collection of methods. However, with increasing complexity of studies, this collection of methods has neither heads nor tails, and is prone to errors. Such pitfalls can make the manuscript cumbersome to read or even question the validity of the research. Generally, journals do have guidelines on how the methods should be formatted, how many words, but not necessarily what to contain because it varies from field to field. I believe there should be a more systematic approach to it. So in this post, I aim at describing some aspects of the Methods section, and then propose a structure that (mostly) fits the general Geodynamics studies.

1. The scientific Methods section

The Methods section is considered one of the most important parts of any scientific manuscript (Kallet, 2004). A good Methods section allows other scientists to verify results and conclusions, understand whether the design of the experiment is relevant for the scientific question (validity), and to build on the work presented (reproducibility) by assessing alternative methods that might produce differing results.

Thus, the Methods section has one major goal: to verify the experiment layout and reproduce results.

It is also the first section to be written in a manuscript because it sets the stage for the results and conclusions presented. So, what exactly do you need to include when writing your Methods section? The title by T.M. Annesley (2010) puts it perfectly into words: “Who, what, when, where, how, and why: The ingredients in the recipe for a successful methods section”.

  • Who performed the experiment?
  • What was done to answer the research question?
  • When and where was the experiment undertaken?
  • How was the experiment done, and how were the results analyzed?
  • Why were specific procedures chosen?

Across sciences, the Methods section should contain detailed information on the research design, participants, equipment, materials, variables, and actions taken by the participants. However, what that detailed information consists of, depends on each field.

2. The Methods section for numerical modeling in Geodynamics

I propose below a structure for the Methods section intended for numerical simulations studies in Geodynamics. I want to mention that this structure is meant as a suggestion, especially for ECS, and can be adapted for every individual and study. Geodynamics studies may have different aspects: a data component (collection, post-processing), a theoretical (mathematical and physical) framework, a numerical framework (computational) and an analog component (laboratory experiments). The majority of studies have 1-2 of these components, while few will have all of them. In this post, I will focus primarily on studies that use numerical simulations to address a question about the solid earth, thus having primarily a theoretical and numerical component.

Before I start, I think a great Methods section is like a cake recipe in which your baked cake looks just like the one in the photo. All the ingredients and the baking steps need to be explained precisely and clearly in order to be reproduced. We should aim at writing the Methods with this in mind: if someone were ‘to bake’ (reproduce) my study, could they succeed based on the instructions I provided? There are many ways how to write your Methods, my way is to break it into logical sections, going from theoretical elements to numerical ones.

Proposed structure:

  1. Brief outline – A general paragraph describing the study design and the main steps taken to approach the scientific question posed in the Introduction.
  2. Theoretical framework – Any numerical simulation is based on some mathematical and physical concepts, so it’s logical to start from here. And from the most important to the least important.
    • 2.1 Governing equations – Section describing the conservation of mass, momentum, energy.
    • 2.2 Constitutive equations – Section describing all the other elements entering the conservation equations above such as: rheology (deformation mechanisms), equation of state, phase transformations, etc. Each of these topics can be explained separately in subsections. For example,
      • 2.2.1 Rheology
        • 2.2.1.1 Viscous deformation
        • 2.2.1.2 Plastic deformation
        • 2.2.1.3 Elastic deformation
      • 2.2.2 Phase transformations
      • 2.2.3 Water migration in the models
    • Figures and tables:
      • Table of parameters – for quick definition of parameters used in equations.
  3. Computational framework – Section explaining how the theory (Section 2) is solved on the computer.
    • 3.1 Numerical methods – code details, discretization methods, programming language, solvers, software libraries used, etc. If you are using a community code, these details should be provided in previous publications.
    • 3.2 Model setup – Section describing the layout of the current experiment.
      • 3.2.1 Details: model geometry, resolution (numerical and physical), parameters, initial and boundary conditions, details on rheological parameters (constitutive equations), etc.
      • 3.2.2 Must motivate the choice of parameters – why is it relevant to address the scientific questions?
    • Figures and tables:
      • Table of parameter values, rheological flow laws used.
      • Table with all model details (to reduce text).
      • Figure illustrating the model geometry, initial and boundary conditions.
    • *NOTE: If you are testing/implementing a new feature in the code, you should allocate a new section for it. Also, spend more effort to explain it into details. Do not expect many people to know about it.
  4. Study design – Section describing the layout of the study.
    • 4.1 What is being tested/varied? How many simulations were performed (model and parameter space)? Why perform those simulations/vary those parameters?
    • 4.2 Code and Data availability – code availability, input files or other data necessary to reproduce the simulation results (i.e., installation guides). Many journals today only accept for publication studies in which data and code availability is declared in standard form (i.e., AGU journals). Some other questions to answer here: where were the simulations performed? how many cores? can I reproduce data on laptop/desktop or do I need access to a cluster?
    • Figures and tables:
      • Simulations table – indicating all simulations that were run and which parameters were varied. When the number of simulations is high (i.e., Monte-Carlo sampling) you should still indicate which parameters were varied and the total number of simulations.
  5. Analysis of numerical data – details on visualization/post-processing techniques, and describe how the data will be presented in the results section. This is a step generally ignored, but be open about it: “visualization was performed in paraview/matlab, and post-processing scripts were developed in python/matlab/unicorn language by the author”. If your post-processing methods are more complex, give more details on that too (i.e., statistical methods used for data analysis).

 

Before you think you’ve finished the Methods section, go over your assumptions, and make sure you’ve explained them clearly! Geodynamics is a field in which you take a complex system (Earth or other planetary body) and simplify it to a level that we can extract some understanding about it. And in doing so, we rely on a physically consistent set of assumptions. It is important to bear in mind that this set of assumptions may not always be obvious to the audience. If your reviewers have questions about your methods and interpretation of results (that you think is obvious), it means that something was not clearly explained. Be pre-emptive and state your assumptions. As long as they are explicit and consistent, the reviewers and readers will find less flaws about your study. Why that choice of parameters? Why did you do it that way?

3. A few other things…

It’s good practice to write a complete Methods section for every manuscript, such as one following the structure above. However, some journals will ask for a short version (1-2 paragraphs) to be included in the manuscript and have the complete Methods section in a separate resource (i.e, Supplementary Data, Supporting information, repository) such that it’s made available to the community. For some other journals, it will be difficult to find a balance between completeness (sufficient details to allow replication and validity verification) and conciseness (follow the guidelines by journals regarding word count limits).

To master the writing of the Methods section, it is important to look at other examples with similar scope and aims (especially the ones you understood clearly and completely). It is also a good idea to keep notes and actually start writing up your equations, model setup, and parameters as the study progresses (such as the mandatory lab notebook).

Finally, some tips on the style of writing of the Methods section:

  • be clear, direct, and precise.
  • be complete, yet concise, to make life easy for the reader.
  • write in the past tense.
  • but use the present tense to describe how the data is presented in the paper.
  • may use both active/passive voice.
  • may use jargon more liberally.
  • cite references for commonly used methods.
  • have a structure and split into smaller sections according to topic.
  • material in each section should be organized by topic from most to least important.
  • use figures, tables and flow diagrams where possible to simplify the explanation of methods.

The Starter Pack for Early Career Geodynamicists

In the interest of not letting the dust accumulate, the growing collection of useful Geodynamics ECS posts (from/for the community):

References:

Kallet R.H. (2004) How to write the methods section of a research paper, Respir Care. 49(10):1229-32. https://www.ncbi.nlm.nih.gov/pubmed/15447808

Annesley, T.M. (2010) Who, what, when, where, how, and why: the ingredients in the recipe for a successful Methods section, Clin Chem. 56(6):897-901, doi: 10.1373/clinchem.2010.146589, https://www.ncbi.nlm.nih.gov/pubmed/20378765

Writing your own press release

Writing your own press release

Do you have an upcoming publication and would like to extend its reach through a press release? Maybe your university doesn’t have a media office able to help, you are short on time, and/or don’t know where to start. Don’t fret, this week Grace Shephard (Researcher at CEED, University of Oslo) shares some tips for writing your own press release and includes a handy template for download. She also spoke to experts from the EGU and AGU press offices on writing a pitch to the media.

A press release is a really easy way to maximise the reach and impact of your latest paper. However, you might think that press releases are only reserved for papers in “high impact” journals or are written by magical gnomes that live in everyone else’s science garden but your own. But I think every research output deserves to be, and can be, shared in a concise, digestible, and fun way. Plus, without an enthusiastic journal handling editor or university media office on hand, it is often up to you – the author or co-author – to write it. Need a few more reasons? Well, the taxpayer likely pays for some of your funding, and science should be accessible for everyone. You’ve spent a long (*cough* sometimes very long) time and expended a lot of effort preparing and publishing that manuscript so spending a little extra effort with outreach won’t hurt. And even if your paper is behind a paywall this is a great way to share the main results and context in a format that isn’t the scientific abstract.

And finally, your own friends and family are much more likely to click on it than that boring looking DOI hyperlink that may have crawled its way onto your social media page. And who knows, they may actually ask you about your research sometime…

This gnome is too busy working on someone else’s press release. Credit: Craig McLauchlan (Unsplash)

What should a press release include?

You’ve all read press releases or science news write-ups before (examples included at bottom) but here are some tips for writing your own. The template is located just below:

    • Catchy headline – We’re not in the business of click-bait, unless it is nerdy scientific click-bait! Think informative but catchy and concise.
    • Cover image – Possibly more important than the headline. Find a fun photo or schematic image that is enticing. You could adapt one from your paper (but please not that snore-fest of an xy plot – keep that in the paper), or why not check out the EGU Imaggeo photos, or other online photo repositories for inspiration? Remember copyright/attribution.
    • Ingress – Ok, so they’ve clicked on your link and then will next read the first ~3-4 sentences. The ingress should summarize the main finding(s), the journal it was published in, and key author info. You can think of this like a tasty hint for the main body of the press release.
    • Jargon – Keep the tricky lingo on the down-low. Remember, you are writing for a diverse audience and should avoid jargon – or when it is unavoidable, define it! This is relevant for both the ingress and the main text. For tips on avoiding jargon see here. Being able to identify jargon is also applicable when writing those Plain Language Summaries that are increasingly featuring alongside published articles. The EGU Communications Officer Olivia Trani also provides some wise advice “When writing blog posts for the general public, science writer Julie Ann Miller says it best: ‘Don’t underestimate your readers’ intelligence, but don’t overestimate their knowledge of a particular field.’ As you discuss certain regions, processes, ideas, and theories, make sure you clearly show why they are important and what implications are present”.
    • Main text – Keep it short-ish – it is much more likely to be read in its entirety at 3-4 short paragraphs, or somewhere between 500-800 words. Writing in the third person and an active voice is probably the easiest and feels less like one is ‘tooting one’s own horn’. Mention the key results, some background and context, how the results were obtained (e.g. methods – keep it in logical order). Finally, the press release could mention what is novel about this work and maybe even what the study doesn’t address and any avenues for future research. Include subheadings to break it up or frame it around questions. Nanci Bompey, Assistant Director for Public Information at AGU suggests: “For scientific studies, the news should tell the reader what the researchers found – their main discovery or conclusions. Don’t let the study itself be the news; the study’s results are the news.
    • Think “big picture” – Remember to place your results in the broader context – why should the reader care? Hot topics like earthquakes, volcanoes, climate, sea-level, or Mars, may seem to quickly attract the readers so your challenge is to be creative and find nerdy analogies and indirect consequences no matter what your topic!
    • Images and video – Include 2-3 images to explain processes and highlight the results. A video or animation will collect bonus points too (check out this amazing video about the Iceland Hotspot). Include a caption and remember attribution. Another tip is if you’re creating original image content, consider adding a little watermark or signature in the image. Also consider putting yourself in the picture too – readers often relate more if they see the human face(s) behind the research (see also ‘Scientists who Selfie Break Down Stereotypes’).
    • Proof read – Ask a colleague or friend, either within or outside of the geosciences, to proof read.
    • Contact author – Include again the reference and link to the article, and who to contact for more info.
*Download the press release template and check-list here as a PDF *
When should it appear online?
    • As soon as possible – It’s up to you, of course, but ideally as close to the online publication date of the article as possible. You might like to wait until the nice proof versions are online, however, that can take weeks to months and you may run out of steam by then. 
Where to post the press release?
  • University webpage – If you have a media/communications office at your institute or university do get in touch with them to ask about options. Your post will likely appear on a university webpage and they will likely have an account that will re-share the press release on the likes of Phys.org and other news websites.
  • Personal website – In the event that a university-hosted platform doesn’t exist you could upload the release to your own personal page or blog. You’ll probably like to re-post it there anyway.

A short clip from – Film about the Creation of Iceland – by Alisha Steinberger and associated with press release for Steinberger et al. (2018; Nat.Geosci).

Maybe you want pitch your press release (or a shorter/alternative version of it) at an even bigger platform – here are some more possibilities.

  • EGU blogs – There are more options here than you can poke a stick at. Along with the other EGU Division Blogs we here on the GD blog welcome content related to your latest paper – just look up an editor’s contact details! You can also approach the EGU Communications and Media team directly:
      • You can send in a pitch for the EGU GeoLog which can include reports from Earth science events, conferences and fieldwork, comments on the latest geoscientific developments and posts on recently published findings in peer-reviewed journals.  For example, I tried my hand at GeoLog with ‘Mapping Ancient Oceans’ and received some really useful feedback from the EGU team!
      • If you are publishing research in one of the EGU journals that you believe to be newsworthy, you can pitch your paper to media@egu.eu . They regularly issue press releases on science published in EGU journals – as EGU’s Media and Communications Manager Bárbara Ferreira notes, “however, that we would prefer to hear about it even before the paper has been accepted: preparing a press release can take some time so it’s useful to know well in advance what papers we should be looking at. Naturally, any press release would be conditional on paper acceptance and would only be published when the final, peer-reviewed paper is published in the journal.”
  • AGU’s Eos Eos is another ‘Earth and Space Science News’ platform to send your pitch for an article.
    Heather Goss, Editor-in-Chief of Eos, suggests that when writing a pitch to the media you “keep your pitch between 200 and 500 words. (You can link to your research, or include more detail at the end of the message.) Begin with a sentence or two that highlights the article’s focus: Do you have an exciting finding? Is it a new method? Did it raise an interesting new question? Explain both the focus and what it is right up front. Then break down your research into 2-3 key points that you want to get across to the journalist. This might be your research method, a challenge that you had to overcome for the result, or it might simply be breaking down your research finding into a few digestible pieces. If there is a fun detail that adds colour, here is the place to add it. Finally, explain in a sentence or two why the publication’s audience should care. It helps the journalist put your work in context, and shows that you understand the outlet you’re pitching to—this is a crucial step if you’re actually writing the piece that would be published, as with Eos.”
  • Other Science news outlets – you could approach freelance journalist, local radio or news station, or those behind the popular sites like ScienceAlert, The Conversation (more in-depth), IFLS, National Geographic, Science Magazine etc. However, they receive a lot of mail and only follow up on selected pitches so just see what happens! 
Some additional tips before we part:
  • You can also use a little glossary or side bar to explain unavoidable technical terms (for example, “subduction” and “plate tectonics”, are terms I find hard to avoid).
  • Writing in English would reach a wide audience but consider including a shorter summary or translation to other languages.
  • Add hyperlinks and references for more info.
  • Include some direct quotes – if you write in third person then it makes it a little less awkward to quote yourself. You could also add a quote from a co-author or someone not-related to the study.
  • Need more inspiration? – head over to your favourite science news website, EGU GeoLog, or check out EGU/AGU’s social media accounts and take a look on how others write-up science news and press releases.

A couple more examples of press releases or similar-style science news articles:

I hope you find some of the tips above of use, and good luck with writing!

 

Thanks very much to Olivia Trani and Bárbara Ferreira (EGU), and Heather Goss and Nanci Bompey (AGU) again for their press release, pitch and outreach tips!

 

 

It doesn’t work! (Asking questions about scientific software)

It doesn’t work! (Asking questions about scientific software)

Numerical modelling is not always a walk in the park. In fact, many of us occasionally encounter problems that we cannot directly solve ourselves, and thus rely on help from others. In this month’s Wit & Wisdom post, Patrick Sanan, postdoctoral researcher at the Geophysical Fluid Dynamics group at ETH Zurich, will talk about asking the right questions about scientific software. As an experienced scientific software developer, Patrick has often been at the “receiving end” of questions regarding numerical modelling and hopes to guide you through some important points that could make life for you as well as your ‘helper’ a lot easier.

 

Patrick Sanan is a postdoctoral researcher at the Geophysical Fluid Dynamics group at ETH Zurich

Numerical modelling is essential for geodynamics; since we cannot directly measure relevant phenomena, we partake in the magic of making a set of reasonable assumptions, setting up a model, and letting a system evolve to produce insight. It’s beautiful. We gain an understanding of the subtle-yet-fundamental processes which shaped our apparently-so-special Earth. We turn our eye beyond, to other planets.

I’m not here to talk about that, though. I’m here to discuss an ugly part of the job, which can bring all the profundity to a screeching halt: what to do when the code doesn’t work.

You know the situation. You’re stuck. There’s no output. Segmentation fault. Error Code -123. You didn’t sign up for this…

You don’t know where to start looking. Is it your model parameters? Your physical assumptions? Are you using the code as intended? Is it your compiler? Can it be the cluster? Your .bashrc? Is your keyboard plugged in?

You’re frustrated. No one around you has a good suggestion. Why are these cruel computers doing this to you?

What to do? Ask for help, in the right way. In this blog, I’ll point out some facts about scientific software, try to use them to formulate an effective email in which you ask for help, and then try to extract some guiding principles.

Some Points on Scientific Software

First, I’ll list some observations I, as a developer, have made about scientific software:

  • Scientific software projects are usually short on maintainers and time.
  • Software designers are not psychic, but they are often experts at deductive problem-solving.
  • Reproducible, bisectable problems are surprisingly easy to solve. Other problems are surprisingly difficult.
  • Working reference cases are very valuable.
  • Sufficiently-complex computing tasks must be treated like lab experiments: one must document the setup and control as many factors as possible.
  • The solutions to most problems are obvious, once found.
  • Numerical software is harder to test than generic software, because floating point arithmetic and parallel computing lead to acceptable differences in numerical output. Higher-level understanding of physics or (parallel) numerical methods is often required to know if something is a “real problem”.

With these as a guide, let’s consider how one might try to resolve a confusing issue.

No pretty pictures here, just error messages (if you’re lucky).

Asking for Help: The Bad Way and the Good Way

Email is a common way to ask for help, as often the person who can best help you is across the world. Let’s say that I’m using a regional lithospheric dynamics code called Rifter3D. I’ve come across an error I have no explanation for. I can’t figure it out, so I write an email to developers of the code. You might also write to a dedicated help address.

Hello - I'm using Rifter3D but on our local cluster I get this error:

/cluster/shadow/.lsbatch/1559505025.92314771: line 8: 951 Segmentation fault (core dumped) ./rifter3d -options_file options.opts

Do you know what I'm doing wrong?

The person on the other end wants to help, but has no information to work with and doesn’t know how much of their time you’re asking for. There is a better way:

Hello - I'm having some trouble diagnosing a problem using Rifter3D and was hoping
you could give me some pointers.

I've been working with Prof. XYZ and have modified a rifting scenario from XYZ et al. 2017 to study the effects of varying A on B. When I run a small case on my laptop, the simulation finishes as expected. I use the attached options_small.opts and run mpiexec -np 4 ./rifter3d -options_file options_small.opts. I'd like to run a bigger case (512 x 256 x 64) for 300 million simulated years, on 64 cores on our cluster.
However, my job fails, producing a segmentation fault almost immediately. I attached the job submission script (job.sbatch), and output from my run (lsf.o92314771). I am using the cluster's existing PETSc 3.11 module, and version 1.0.3 of Rifter3D. I can successfully run a simple isoviscous setup on this cluster - see attached job_small.lsf, option2.opts, and lsf.o92314681

Do you have any insight as to how I might be able to run this simulation?

Best,
E. Scholar

Attachments: options_small.opts options.opts job.lsf job_small.lsf options2.opts lsf.o92314771 lsf.o92314681

The recipient will likely respond with more questions as you work towards resolving the issue. Perhaps they’ll ask you for more information about how you built Rifter3D, or point out some unusual settings in your options file.

Why is this second email better? It is not simply longer, but

  • It clearly describes the problem. Just trying to precisely describe a problem has an almost-magical clarifying effect, and the solution will often appear. Software engineers call this rubber ducking.
  • It explains the true objective and how the problem is to be resolved. This is important to avoid the XY problem, describing a problem with a method to achieve a goal, without mentioning the goal itself.
  • It gives concrete information to reproduce the problem: the version of the code, input files, and launch commands/scripts.
  • It provides enough output to allow deductive reasoning, more than just a copy-and-pasted error message.
  • It’s polite
  • It shows some effort has already been put into investigating.
  • It notes similar, working cases.
  • It’s not too long, but it is detailed enough to allow for quick, intelligent follow-up questions. Supporting data are included as attachments or links.
  • It doesn’t make too many assumptions about the cause of the problem.

Boiling it Down: 3 Questions to Ask Yourself

When asking for help, consider these three questions. They will help with the central objective: clearly describing the problem.

  • Why do you need it to work?
    What is the context? What is the goal?
  • How do you show that it doesn’t work?
    What are the steps to reproduce your problem?
    How will you know that the problem is resolved?
  • What does work?
    How far are you from a working state? What similar cases work?

Here is a 1-page pdf which you can print out, with some of this advice:

Pdf and LaTeX source on GitHub

The “Real” Answer

To conclude, I will try to avoid an “XY problem” of my own. The most efficient way to resolve bewildering problems is to avoid them. To make an alpine analogy, the most important topic in avalanche safety is not how to dig someone out, it’s how to avoid risky terrain.

Real-life debugging. Avoid if at all possible (from Wikimedia commons)

First, borrow techniques from software engineering. Version control (e.g. git) will encourage you to save working states, amongst many other benefits. Next, leverage your intuition and experience as a geodynamicist. Always be able to quickly run and verify small, quick, simple cases, and test and visualize often. Look out for simple cases where you “know the answer ahead of time”: established benchmarks and analytical solutions.

The points in this article can help everyone save time (and not just running geodynamical models!): problems will be resolved more quickly, bugs will get fixed faster, and more time can be spent exploring more interesting questions than “Why doesn’t it work?”.