Grant application tip: Aim, Objective, Task; what are they? when to use them?

By Nicolas Gambardella

Aim, objective, goal, target, and purpose, those words are used mostly interchangeably in everyday speech. However, when writing a grant application, they cover different concepts, often at odds with the subtle differences you would expect from common usage. The most used words to describe mandatory application elements are aim and objective; even if within the text, goal and purpose are also frequently found. Briefly and approximately, the aim is the why, the objectives are the what, and the tasks are the how. The aim represents the purpose, the target, while the objectives represent the means to reach it. Think about the objective of a microscope or a riffle. It is true that in everyday language, you aim at the target, the aim being the cross you need to align with the target to reach it. But words may have different meanings, based not only on the official definition found in dictionaries but also on usage in given contexts. Note that some funding agencies swap the concepts behind aim and objectives (e.g., the Israeli Cancer Research Fund), using them in a sense closer to everyday meaning. However, after reading this post, you will quickly identify which is which, and adapt consequently. The task is a third concept we need to differentiate from the aim and the objectives.

[Note that while this post uses examples from scientific activities, the distinction between the three terms holds true for any grant application. I’ll let the reader have the task of drafting examples for humanities.]

The aim of the project is its overall purpose. This is why the funding agency or foundation should fund the project. In the “impact onion” (expect a future post on that concept), the aim with lead to the overall scientific or societal impacts. Accordingly, the aim should not be expressed in a language that can be understood only by the experts of your field but rather by the wider impacted population. More importantly, the aim should not be expressed in a language that can be understood only by the reviewers or your introducing members (the panel members specifically in charge of your application, often chosen for their knowledge of the topic) but by all members of the funding panel. The last point is essential since most panels – even specialist ones such as the ERC Advanced Grant panels – are made up of people with different backgrounds who have often been isolated in their research echo chamber for decades. In domains as close as Machine learning in genomics, Pharmacometrics, and Systems Biology, words such as model, compartment, or noise have fairly different meanings. This is even more important if you apply to an interdisciplinary scheme whose panel will feature people from different backgrounds. An extreme example would be the Sinergia funding from the Swiss National Science Foundation, which comprises people as diverse as historians, literature and art experts, sociologists, mathematicians, physicists, engineers, ecologists, biologists and clinicians (Mind you, this does not mean the language can be approximate and the content of the aim fuzzy! Never waffle in a grant application, no matter the section and its perceived importance).

An example of aim could be:

We will treat cancer of the left buttock cheek.

The project’s objectives are the steps you will build to reach your aim. They could be seen as sub-aims or subprojects. In the impact onion, the objectives might impact science and society at large, but their outcomes might profit mainly to the relevant scientific field. Accordingly, objectives can be expressed in a more domain-specific language if necessary. However, you should still endeavour to make them accessible to all panel members. Ideally, objectives should describe achievements resulting from the project activities rather than describing how the work will be performed. Note that the objectives are not necessarily aligned with work packages, which are sets of related tasks (more on that later). objectives are also not necessarily disjoints because an activity performed during the project can contribute to several objectives. Moreover, work towards different objectives can proceed in parallel.

Examples of objectives for the aim presented above could be:

1) we will define a molecular portrait of the cancer of the left buttock cheek;
2) we will look for molecules able to inhibit oncogenes or stimulate tumour suppressors;
3) we will validate the promising molecules.

A task is a research project’s simplest, more explicit element. It describes an activity or a set of activities contributing to one or more objectives of the project. A task possesses a defined start and a defined end; and, thus, a duration. Specific people contribute to a task during part or all of it, resulting in an effort often expressed in person·months (not person/month or person-month. The dot is a product. The effort is the number of contributors multiplied by the number of months spent by contributor). The results of a task are often dubbed deliverables. Such a deliverable can be a conclusion (delivered as a report), a dataset, an artefact, etc. These deliverables may have an immediate impact on very specific populations in the inner layer of the impact onion, such as people working in the same field as the project partners. If performing a task depends on the successful achievement of another task, we say that those task are linked by a dependency. Related tasks are often grouped into work packages. Tasks are the elements represented on Gantt charts and should also be the elements of PERT diagram. However, complex projects sometimes simplify the latter by using work packages (if a project is structured correctly, PERT diagrams with tasks and work packages should exhibit the same connectivity).

Examples of tasks for our cancer project could be:

T1.1) sequence the genomes and transcriptomes of left buttock cheeks from patients and controls;
T1.2) compare the transcriptomes;
T1.3) look for eQTLs explaining the differences observed in T1.1.

T2.1) analyse the function of differentially expressed proteins and proteins containing eQTLs;
T2.2) screen the public data resources for possible molecules targeting the proteins studied in T2.1;
T2.3) filter the list obtained in T2.3 for availability, desirable chemical properties, ADME profile, and possible side effects.

T3.1) study the pharmacological profile of the best hits from T2.3 on relevant cell lines;
T3.2) build animal models of the cancer of the left buttock cheek using the mutated targets of T2.3;
T3.3) test on the animal model the molecules presenting an adequate profile in T3.1.

In our simple example, all the tasks are linked by dependencies and can only be performed sequentially. In a real-world setting, the situation would, of course, be more complex, with some tasks running in parallel, linked through intermediate or continuous results, etc.

The aim is the why, the objectives are the what, and the tasks are the how.

De la ponctuation des listes, Une Règle pour les Gouverner Toutes

Par Nicolas Gambardella

Quelle ponctuation utiliser dans les listes à puces ou numérotées ? Si l’on essaie de comprendre les règles en accumulant les exemples, le découragement vient rapidement, car il semble que le hasard règne en maître. Si l’on trouve une liste de ces règles, le soulagement est de courte durée tant celles-ci semblent arbitraires et les exceptions nombreuses. Je vais proposer à la fin de ce billet un algorithme graphique en deux parties, pour vous aider à choisir la casse des premières lettres des éléments de liste et la ponctuation à la fin de chaque élément. Mais avant, ça je vais fusionner toutes les règles en une seule, et présenter des exemples vous aidant à la comprendre.

Avertissement : ce billet ne concerne que les listes insérées dans des textes. S’il s’agit de listes insérées dans des diapositives de présentations, la rapidité de lecture et la facilité de mise en page doit être prise en compte, et on préférera souvent commencer chaque élément par une majuscule et omettre la ponctuation à la fin de celui-ci.

Revenons à cette fameuse unique Règle pour les Gouverner Toutes ; quelle est-elle ? C’est tout simple :

Si on supprime le formatage de la liste, à savoir, passages à la ligne et puces,
la ponctuation du texte résultant doit rester correcte.

Prenons une liste simple.

Le cerveau comporte trois grandes parties :
le prosencéphale ;
le mésencéphale ;
le rhombencéphale.

Si l’on supprime le formatage de la liste ci-dessus, on obtient :

Le cerveau comporte trois grandes parties : le prosencéphale ; le mésencéphale ; le rhombencéphale.

La ponctuation de cette phrase est tout à fait correcte puisqu’elle commence par une majuscule, ne contient pas de majuscules au milieu, suivant les deux-points et les point-virgules, et se termine par un point.

Aparté : le tiret commençant l’entrée d’une liste est un tiret semi-cadratin « – ». Ce n’est ni un trait d’union « - », ni un tiret cadratin « — », ni bien sûr le symbole mathématique moins « − ». Ce tiret est suivi d’une espace insécable, comme il l’est quand il précède une incise. Fin de l’aparté.

On ferme chaque élément par une ponctuation non fermante, sauf le dernier. On aurait pu remplacer les point-virgules par des virgules. Dans ce cas, on aurait également pu ajouter la conjonction de coordination « et » après le pénultième élément (après la virgule !).

Le cerveau comporte trois grandes parties :
– le prosencéphale,
– le mésencéphale, et
– le rhombencéphale.

L’absence de ponctuation à la fin de chaque élément, comme l’utilisation d’un point rend la ponctuation incorrecte :

Le cerveau comporte trois grandes parties : le prosencéphale le mésencéphale le rhombencéphale

Le cerveau comporte trois grandes parties : le prosencéphale. le mésencéphale. le rhombencéphale.

Ce serait également le cas si nous avions commencé chaque élément par une majuscule.

Le cerveau comporte trois grandes parties : Le prosencéphale ; Le mésencéphale ; Le rhombencéphale.

Dans la liste précédente, les éléments ne sont pas indépendants de la phrase d’entrée. Ce n’est parfois pas le cas, par exemple si cette dernière est du type « Remarques : » ou « À noter : » (mais pas « À noter que : »). Dans ces cas-là, les éléments de la liste sont des phrases complètes, indépendantes non seulement de la phrase d’entrée, mais également l’une de l’autre. Elles sont ponctuées en conséquence.

Remarques :
– Le prosencéphale  contient la vaste majorité des neurones du cerveau des êtres humains.
– Le mésencéphale est atteint dans la maladie de Parkinson.
– Le rhombencéphale contrôle les fonctions vitales et autonomes.

Remarques : Le prosencéphale  contient la vaste majorité des neurones du cerveau des êtres humains. Le mésencéphale est atteint dans la maladie de Parkinson. Le rhombencéphale contrôle les fonctions vitales et autonomes.

Les listes ci-dessus étaient précédées d’une phrase ouverte, se terminant par deux-points. Cela aurait également été le cas si elle s’était terminée par un point-virgule ou une virgule (voir plus bas le cas des listes emboîtées). Si la phrase d’entrée est fermée, c’est-à-dire qu’elle se termine par un point, un point d’exclamation ou un point d’interrogation, les règles sont différentes, car les éléments sont eux-mêmes des phrases.

Laquelle des informations suivantes est erronée ?
– Le prosencéphale  est la partie la plus antérieure du cerveau.
– Le mésencéphale est atteint dans le diabète sucré.
– Le rhombencéphale contrôle les fonctions vitales et autonomes.

Laquelle des informations suivantes est erronée ? Le prosencéphale  est la partie la plus antérieure du cerveau. Le mésencéphale est atteint dans le diabète sucré. Le rhombencéphale contrôle les fonctions vitales et autonomes.

On voit bien que débuter les éléments par des minuscules et les achever par un point virgule ou une virgule produirait ici une structure incorrecte.

Laquelle des informations suivantes est erronée ? le prosencéphale  est la partie la plus antérieure du cerveau, le mésencéphale est atteint dans le diabète sucré, le rhombencéphale contrôle les fonctions vitales et autonomes.

Ce qui nous amène aux questions à choix multiples (QCM). Cette situation est quelque peu différente, car les éléments de la liste sont des alternatives.

Quelle est la partie du cerveau la plus développée chez l’être humain ?
– Le prosencéphale.
– Le mésencéphale.
– Le rhombencéphale.

La liste peut dès lors être pliée en phrases différentes, correspondant à chaque élément.

Quelle est la partie du cerveau la plus développée chez l’être humain ? Le prosencéphale.

Quelle est la partie du cerveau la plus développée chez l’être humain ? Le mésencéphale.

Quelle est la partie du cerveau la plus développée chez l’être humain ? Le rhombencéphale.

Pour finir, abordons le sujet des listes emboîtées. Les règles restent les mêmes. Le dernier élément d’une liste de niveau supérieur joue toutefois le rôle de phrase entrante pour la liste de niveau inférieur. On utilisera des ponctuations différentes pour les éléments de niveaux différente. Typiquement, une virgule terminera des éléments au sein d’un élément terminé par un point-virgule.

Le cerveau comporte trois grandes parties :
– le prosencéphale qui est la partie la plus antérieure formée de deux parties,
  • le télencéphale qui est responsable des fonctions supérieures,
 • le diencéphale qui relaie les entrées sensorielles ;
– le mésencéphale ;
– le rhombencéphale qui est la partie postérieure formée de deux parties,
  • le métencéphale qui comprend le cervelet,
  • le myélencéphale qui est aussi appelé bulbe rachidien.

Si l’on supprime les listes de second niveau, on obtient la ponctuation correcte suivante :

Le cerveau comporte trois grandes parties :
– le prosencéphale qui est la partie la plus antérieure formée de deux parties, le télencéphale qui est responsable des fonctions supérieures, le diencéphale qui relaie les entrées sensorielles ;
– le mésencéphale ;
– le rhombencéphale qui est la partie postérieure formée de deux parties, le métencéphale qui comprend le cervelet, le myélencéphale qui est aussi appelé bulbe rachidien.

La liste entièrement pliée devient :

Le cerveau comporte trois grandes parties : le prosencéphale qui est la partie la plus antérieure formée de deux parties, le télencéphale qui est responsable des fonctions supérieures, le diencéphale qui relaie les entrées sensorielles ; le mésencéphale ; le rhombencéphale qui est la partie postérieure formée de deux parties, le métencéphale qui comprend le cervelet, le myélencéphale qui est aussi appelé bulbe rachidien.

Essayons de construire un algorithme qui nous permet de trouver à coup sûr quelle casse et quelle ponctuation utiliser. Commençons par la casse de début d’élément.

Nous pouvons ensuite nous tourner vers la ponctuation terminant les entrées. Notons que je ne considère ici qu’un seul niveau d’imbrication. L’algorithme pourrait être généralisé en remplaçant points-virgules et virgules par ponctuation ouverte de niveau n et n+1.

Et voilà ! Vous pouvez maintenant être confiant·e dans le formatage de votre liste !

Tips for translating a novel

By Nicolas Gambardella

In a previous blog post, I already covered a few tips for new translators. These, of course, apply to the translation of any text document. At aSciStance, I specialize in technical documents, particularly from the health and life sciences sectors. However, I have a secret life. In the evenings, I translate sci-fi novels. Besides the rules described before, there are a few do and don’t that apply when translating a novel. Here are some, in no particular order.

The most important thing when translating a novel (and presumably writing it in the first place) is to keep the reader enthralled. This generally requires an easy and smooth reading (I will put Lovecraft and Joyce aside…). As a result, the form becomes very important, and you should not necessarily need to stick 100% to the source. A word-for-word translation will be close to unreadable. Moreover, sentence segmentation tends to vary between languages. Therefore, some splitting and merging will be unavoidable. If the translation of a long proposition with many adjectives results in a boring or confusing piece of text, do not hesitate to replace it with a terse and punchy alternative. Conversely, depending on the source and target language, you might want to expand a single word in a lengthier piece of text. Such an expansion might also be needed if a piece of information is common knowledge in the population using the source language but not the population reading the target one (for instance, historical events or monuments).

You should, therefore, not hesitate to “find your voice”. The actual story is obviously paramount. However, the rhythm, the tone of the dialogue, the level of language, all participate in telling this story. These will change between languages. When I translated The Night of the Purple Moon, I chose to define three different levels of languages for three different groups of teenagers. The main protagonists were brought up in an upper-middle-class setting, where the father was a librarian. Their language is correct but not too posh. While to distinguish between some of the unruly boys, I used a more familiar language register, even a bit of slang (although profanities were a no-no). On the contrary, a couple of children were foreigners, coming from a country with different levels of deference. They learnt English from books and make use of a very polite, slightly old fashion, language (for instance, calling their parents “mother and father” rather than “mom and dad”).

That said, each novel possesses specific rhythm, tone, terminology, and “feeling”. Sometimes they are part of an author’s trademark and should be respected as much as possible. Lovecraft’s stories would have had a very different impact if his “wholly abominable and unspeakable horrors” had been translated into smooth and easy-to-read pieces. If you choose to change some of those characteristics, make sure to be consistent throughout.

Immerse yourself into the novel’s universe. What counts in a story is self-coherence, not accuracy. Particularly if you are translating a science-fiction novel – like NOPM – and have – like me – a biomedical background, you should not be offended that bacteria or viruses can survive the cold void of space – and the constant radiation – or that they can kill a human by recognizing sex hormones they never encountered before. After all, in science-fiction, there is the word fiction…
Do not try to be too exact either. In an imaginary setting, translate 100 miles into 100 km rather than 160.934 km. It just means “quite a long distance”. Except, of course, if this distance is important for the story. As any ultra-marathon runner will tell you, having to travel 100 km or 100 miles are two very different endeavours.

However, do not hesitate to correct the factual errors the author could have committed that you think could bother some readers. Obviously, only do so with the author’s permission. I will not list the instances where I did that in NOPM (you will have to read the English and French versions). But sometimes, such a correction can kill two birds with one stone. In NOPM, the source mentioned that the germs were coming from the space dust. Space dust was not very clear to me. If we were talking about cosmic dust, it is a bit too thin to contain germs. Moreover, “poussière de l’espace” sounds a bit childish in French. However, comet dust fits well with the story and sounds better in French, as “poussière de comète” (although, to be fair “poussière cosmique” sounds even cooler! #NoteForFutureTranslations)

Try to be consistent but not repetitive. If a certain item is always referred by a certain name in the source, try to always use the same term in the translation. In NOPM, the organisms that killed humans are always called “germs”. I chose to use “microbes” and stuck to it. I did not use “germes” or “bactéries”. Similarly, in Colony East (the follow-up from NOPM, which I am translating as I am writing this blog post), I chose to translate “pills” by “comprimés” and I do not use “pilules” or “médicament”. Such consistency facilitates reading, in particular for younger readers.

However, use such consistency sparingly when it comes to entire expressions. It is sometimes quite annoying to find exactly the same description, or the same bit of dialogue, several times. This is particularly true if the occurrences are in the same chapter. This problem is increased by Translation Memory-based CAT tools, and you should be cautious when using such tools (which I do. I use Cafetran Espresso).

This brings me to the final piece of advice. Now that you have translated your text, check it, check it, check it.

1) Use a Machine Translation engine (such as DeepL) to reverse translate your work. Are there inconsistencies between the result and the original text? Does that reveal a potential for confusion in the reader’s mind?

2) Proofread your work with dedicated software. I use three of them at the moment, Grammarly, Grammalecte, and LanguageTool. Yes, you are a fantastic linguist. But even the keenest eye might miss the occasional typo or doublet.

3) Read back every chapter after completing the translation. Read them aloud. Reading a piece of text aloud forces you to slow down, be more attentive to every word, and better detect subtle grammatical errors.

Here are a few links to other relevant web pages. Please feel free to suggest others in your comments.

10 tips to model a biological system

By Nicolas Gambardella

You are about to embark on a system biology project which will involve some modelling. Here are a few tips to make this adventure more productive and pleasant.

1 – Think ahead

Do not start building the model without knowing where you are going. What do you want to achieve by building this model? Is it only a quick exercise, a one-off? Or do you want this model to become an important part of your current and future projects? Will the model evolve with your questions and the data you acquire? A model with a handful of variables, created to explore an idea quickly, and a model that will be parameterised with experimental measurements, whose predictions will be tested and that will be further expanded are two completely different beasts. Following the 9 tips below in the former case is overkill, a waste of time. However, in the latter case, cutting corners will cause you unending pain when your project unfolds.

2- Focus on the biology

A good systems biology model aims to be anchored in biological knowledge and even (generally) reflects the system’s behaviours’ biological mechanisms. We are using modelling to understand biology and not using biology to illustrate modelling techniques (which is a perfectly respectable activity but not the focus of this blog post). In order to do so, the model must be built from the processes we want to represent (hence complying with the Minimum Information Requested in the Annotation of Models). Therefore, try to build up your model from reactions (or transitions if this is a Petri Net, rules for a Rule-based model, influences for a Logic model), rather than writing directly the equations controlling the evolution of variables.

Another aspect worth a thought is the existence of different “compartments”. In systems biology, compartments are the “spaces” that contain the biological entities represented by your variables (the word has a slightly different meaning in PKPD modelling, meaning the variable itself). Because compartments can have different sizes, these sizes can change, and they can be used to affect other aspects of the models, it is important to represent them correctly, rather than ignoring them altogether, which was the case for decades.

Many tools have been developed to help you build models that way, such as (but absolutely not limited to) CellDesigner and the excellent COPASI. These software tools are, in general, very user-friendly and more approachable for biologists. An extensive list of tools is available from the SBML software guide.

3- Document as you build

Bookkeeping is a cornerstone of any professional activity, and lab notebooks are scientists’ best friends. Modelling is no exception. If you do not log why you created a variable or a reaction, what biological entities they represent, how you chose the initial values or the boundaries for parameter estimation, you will make your life down the line hell. You will not be able to interpret the results of simulations, modify the model, share it with collaborators, write a publication, etc. You must start this documentation as soon as you begin building the model. Memory fades quickly, and motivation even quicker. The biggest self-delusion (or plain lie) is “I am efficient and focused now, and I must get results done. I will clean up and document the model later.” You will most probably never clean up and document the model. And if you do, you will suffer greatly, trying to remember why the heck you made those choices before.

Several software tools, such as COPASI, provide means of annotating every single element of a model, either with free text, or with controlled annotations. Alternatively, you can use regular electronic notebooks, Google docs, and spreadsheets if you work with others etc. Anything goes, as far as you do create this documentation. Note that you can later share model and documentation at once, either with the documentation included in the model (for instance, in SBML notes and annotation elements) or with model and documentation shared as a single COMBINE Archive.

4- Choose a consistent naming scheme

This sounds like a mundane concern. But it is not! Variable and parameter names are the first layer of documentation (see tip 3). It also anchors your model in biology (tip 2). A naming scheme that is logical and consistent while easy to remember and use will also greatly facilitate future extensions of your model (tip 1). NB: we do not want to open a debate “identifiers versus accession number versus usable name” or the pros and cons of semantics in identifiers (see the paper by McMurry et al for a great discussion on that topic). Here, we talk about the short names one sees in equations, model graphs, etc.

Avoid very long names if not needed (“adenosine triphosphate”), but do not be over-parsimonious (“a”). “ATP” is fine. Short, explicit, clear for most people within a given context. Reuse common practices if possible, even if they are not official. For instance, uppercase K is mostly used for equilibrium constants, lowercase k for rate constants. A model using “Km” for the rate constant of DNA methylase and “kd” for its dissociation constant from DNA would be pretty confusing. Be consistent in the naming. If non-covalent complexes are denoted with an underscore, A_B being a complex between A and B, and hyphens denote covalent modifications, A-P representing the phosphorylated form of A, do not use CDP for the phosphorylated form of the complex between C and D (or, heaven forbid, C-D_P !!!)

5- Choose granularity and independent variables wisely

We often make two mistakes when describing systems in biology mathematically. The first one is a variant of the “spherical cow“. In order to facilitate the manipulation of the model, it is very tempting to create as few independent variables as possible (by variable, we mean here the things we can measure and predict). Those variables can be combinations of others, combinations sometimes only valid in specific conditions. Such simplifications make exploring the different behaviours easier, for instance, with phase portraits and bifurcation plots. A famous example is the two variable version of the cell cycle model by John Tyson in 1991. However, the hidden constraints might not allow the model to reproduce all the behaviours displayed by the biological system. Moreover, reverse engineering the variables to interpret the results could be difficult.

The second, mirroring, mistake is to try modelling the biological system in exquisite details, representing all our knowledge and thus creating too many variables. Even if the mechanisms underlying the interactions between those variables were known (which is most often not the case), the resulting model often contains too many degrees of freedom, effectively allowing any behaviour to be reproduced with some parameter values (making it impossible to falsify). It also becomes challenging to accurately determine the values of all parameters based on a limited number of independent measurements.

It is therefore paramount to choose the right level of granularity. There is no universal and straightforward solution, and we can encounter extreme cases. d’Alcantara et al 2003 represented calmodulin is represented by two variables (total concentration and concentration of active molecules). In Stefan et al 2008, calmodulin is represented by 96 variables (all calcium-binding combinations plus binding to other proteins and different structural conformations). Nevertheless, both papers study the biological phenomenon.

The right answer is to pick the variable granularity depending on the questions asked and the data available. A rule of thumb is to start with a small number of variables that can be matched (directly or via mathematical transformations) with the quantities you have measurements for. Then you can progressively make your model more complex and expressive as you move on while keeping it identifiable.

6- Create your relationships

Once you have defined your variables, you can create the necessary relationships, which are all the mathematical constructs that link variables and parameters together. Graphical software such as CellDesigner or GINsim permit to draw the diagrams representing the processes or the influences respectively.

Note that some software tools provide shorthand notations that permit the creation of variables and parameters directly when writing the reactions. This is very handy for creating small models instantly. However, I would refrain from doing so if you want to document your model properly (it also makes it easier to create spurious variables and “dangling ends” through typos in the variable names).

Working on the relationships after defining the variables also easily permits the model’s modification. For example, you can add or remove a reaction without having to go through the entire model as you would with a list of ordinary differential equations.

7- Choose your math

The beauty of mathematical models is that you can explore a large diversity of possible linkages between molecular species, actual mechanisms hidden behind the “arrow” representing a process. A transformation of X in a compartment into Y in another compartment can be controlled for instance by a constant flux (don’t do that!), a passive diffusion, a rate-limited transport, or even exotic higher-order kinetics. At that point, we could write: [insert clone of tip 5 here]. Indeed, while the mathematical expressions you choose can be arbitrarily complex, the more parameters you have, the harder it will be to find proper values for them.

If the model is carefully designed, switching between kinetics should not be too difficult. A useful habit to take is to preferentially use global parameters (which scope is the entire model/module) rather than parameters defined for a given reaction/mathematical expression. Doing so will, of course, ease the use of the parameter in different expressions and facilitate the documentation and ease future model extensions, for instance, where a parameter no longer has a fixed value but is affected by other things happening in the model.

8- Plug holes and check for mistakes

Now that you have your shiny model, you need to make sure you did not forget to close a porthole that would sink it. Do you have rate laws generating negative concentrations? Conversely, does your model generate umpteen amounts of certain molecules which are not consumed, resulting in preposterous concentrations? Software like COPASI have checks for this kind of thing. In the example below, I created a reaction that consumes ATP to produce ADP and P, with a constant flux. This would result in infinite concentrations of ADP and infinitely negative concentrations of ATP. COPASI catches it, albeit returning a message that could be clearer.

Ideally, a model should be “homeostatic”. All molecular species should be produced and consumed. Pure “inputs” should be produced by creation/import reactions, while pure “outputs” should be consumed by degradation/export reactions. Simulating the model would not lead to any timecourse tending to either +∞ or -∞.

9- Create output

“A picture is worth a thousand words”, and the impact of the results you obtained with such a nice will be greater if served in clear, attractive and expressive figures. Timecourses are useful. But they are not always the best way to present the key message. You want to show the effect of parameter values on molecular species’ steady-states? Try parameter scanning plots, and their derivatives, such as bifurcation plots. Try phase-portraits. Distributions of concentrations during stochastic simulations or after ensemble simulations can be represented with histograms. And why being limited to 2D-plots? Use 3D plots and surfaces instead, possibly in conjunction with interactive display (plot.ly …).

10- Save your work!

Finally, and this is quite important, save often and save all versions. Models are code, and code must be versioned. You never know when you will realise you made a mistake and will want to go back a few steps and start exploring a different direction. You certainly do not want to start all over again. Recent work explored ways of comparing model versions (see the works from the Waltemath group, for instance). But we are still some way off the possibility of accurately “diff and merge” as it is done on text and programming code. The safest way is to save all the significant versions of a model separately.

Have fun modelling!

10 tips to improve your research articles

By Nicolas Gambardella

Since an important part of our activity is to assist researchers by improving their documents, whether grant applications, research publications or project reports, this blog will come back to this topic on a regular basis. We will write in depth about every aspects of scientific writing in turn. In this initial post let’s go wide and list a few general rules to improve research papers (although most of those apply to grant applications too).

1) Find your message

Of course, any body of scientific research brings about multiple results, that in turns affect the way we understand several aspects of reality, or can lead to a few technical developments. However, in order to maximize the impact of your account, you must choose an angle. What is the main point you want people to remember? What would be the sentence accompanying a tweet linking to your paper?

2) Know your audience

Once you have settled on your message, you need to select the population you want to “sell it too”, on which you expect the maximum impact. By audience, we mean first and foremost the editor and the reviewers. Yes, your ultimate aim is to spread the news through your community. But the paper needs to be published first … Knowing who you are talking to will help you structure the paper, as much as the instructions to authors. What will you put in the main body of the paper and what will you demote to supplementary materials? What should you present in detail or on the contrary gloss over? How will you present the methods and the results? Experimental biologists tend to dislike equations. Biochemists do not care much about the illustrating experiment, but want quantitative tables. Molecular biologists love histograms, and they like to have one illustrating experiment such as a a western blot or a microscopy field.

3) Build a storyline

Keeping in mind both the message you chose and the audience you want to sell it to, create a progressive demonstration that brings the reader to the same conclusions as yours, keeping them focused until the final bang. This is not necessarily how things really happened, in particular chronologically. We all know that scientific research is a complex process, that includes iterative explorations, validations and controls, explode dead ends etc. There is no need to list everything path you explored, every experiment you did. A paper is not a laboratory notebook. However, as you progress towards in your narrative, each step need to naturally lead to the next, while the controls you describe preclude wandering off-path.

4) Keep facts and ideas where they belong

Do not mix Introduction, Materials and Methods, Results and Discussion (in some article structures, the last two can be included in the same section, but the relevant bits are generally in different paragraph). The Introduction should only present and discuss what was known before your work, and only what is needed to understand your work and its context. Similarly, the Materials and Methods section should not describe new techniques or materials. And finally, all your results should be in the Results section (if separate from the Discussion). As a rule, if you remove everything but the Results section, you should not affect the storyline described above. Our advice is to start writing the Results, the add the necessary Materials and Methods as you go, write the Discussion, and finish by the Introduction. You cannot write an effective introduction if you do not know what you want to introduce. Moreover, writing the introduction is often used as a procrastination device …

5) Build modules

Use one paragraph for one idea, if possible linked to one experiment, and illustrated by one figure (whether the figure ends up in the main body or in supplementary materials does not matter). This is sometime challenging when the idea or the experiment are complex. But even if, in the end, paragraphs are merged or split, adopting this approach is useful during the initial writing stage. This will help building the storyline and will enable easy restructuring later. Give a title to each module. Try drawing a flowchart representing your results, and annotate it with experiments and figures.

6) Do not assume knowledge but do not state the obvious

Moving from the structure to the style now. It is always difficult to decide what is common knowledge and therefore should not be explicit, and what is specialized knowledge required to understand your story and accept your message. Do not rely on your own knowledge. Go back to point 2), and make a real effort to put yourself in the shoes of the intended readership. Then a guideline can be to introduce factual knowledge but not common – in your audience’s domain – technical knowledge. For instance, if you write for biologists, you should not assume that people know the Kd between PKA and cAMP is 0.1 micromolar. However, you may assume that readers know increased affinity means lower Kd.

7) Do not repeat information

Building your text following 5) should preclude the description of the same information twice. When you refer to a piece of information described before, you do not need to restate it. This goes for details of experiments as well. If you already stated that an experiment took place in a chemical reactor, there is no need to mention it all the time, as “the solution in the chemical reactor” “the temperature in the chemical reactor” etc.

8) Write clearly, concisely and elegantly

I strongly recommend reading, and keeping a copy at hand, “Style: Lessons in Clarity and Grace“. There are many simple habits you can use to improve the readability of a text. Avoid passive forms. Keep verbs for actions and nouns for what perform or is affected by such actions. Try to stick to one proposition per sentence, twice at most (and well articulated). Do not add words needlessly. Instead of writing “the oxidation of the metal”, write “metal oxidation”. A shorter text is read faster and is easier to memorize.

9) Avoid casual writing

A scientific article is not a diary (or a blog post …). Your reader is neither your mate nor your student. Avoid talking to them directly, e.g. “you can do this” or indirectly as “let’s consider this first”. This is not a huge deal, but it might be irritating for some people. In general, adopt the style commonly used in the most respectable journals of the community you are targeting.

10) Chase grammatical errors and spelling mistakes

They are less important than the scientific facts, and hopefully they will disappear during the proof-reading stage. However, they give a hint of sloppiness, and they will annoy the reviewers. Even if those reviewers do not belong to the type focusing on such things, unconscious biases can taint even the fairer person. So read your manuscript again and again, slowly and aloud. More importantly ask someone else, if possible not a co-author, to read it as well.