Earth Science

Asking for help sometimes can save your life. But how, where, when ask for help is always a challenge.

Earth science is interdisciplinary field, which means you have to learn lots of skills to get jobs done. Unless you are completely dependent upon other team members, we must learn skills efficiently.

Having a PhD degree never means you know everything in your field. In fact, in Earth science, PhD is merely the starting line.

Below I will give a life example.
As a modeler, I deal with lots of different technical problems and I have the opportunities to work with many great team members. But lots of time, none of member can solve your problem because maybe no one has ever encountered the same problem as you have.

For example, when I was trying to setup a E3SM simulation. Some of us use the CIME directly. And some use the bash script. Also there are also some prefer to use Matlab. My preference is Python. The problem is unless I talk to every single member of the group, I wouldn't k…

This post was an answer to my own question: https://twitter.com/changliao1025/status/1182847707666247680

When you write code for many moons, usually you will develop some sort of shared library/package for various projects.
These Python scripts may not be suitable for deployment as a package but you still want to use them anywhere.

Another issue is that I often need to write and run code cross platform/cluster. So I want to make sure there is an easy way to configure my code so that I don't have to modify things when I update something.

In my early attempt, I put everything into a package and use the following method to use them in any source code:

With these global variables, now I can import any function within the package:

This seems to work well at the beginning, however, I have to copy/paste this about 20 lines of code in lots of functions. And if I want to add new capability, I have to modify all of them!

So I am on a new quest to fix it.

After digging a little bit, I was a…

I have been involved with the E3SM development since I joined PNNL as a postdoc. Over the course of time, I have learnt a lot from the E3SM model. I also found many issues within the model, which reflects lots of similar struggles in the lifespan of software engineering.

Here I list a few major ones that we all dislike but they are around in almost every project we have worked on.

Excessive usage of existing framework even it is not meant to Working in a large project means that you should NOT re-invent the wheels if they are already there. But more often, developers tend to use existing data types and functions even when they were not designed to do so. The reason is simple: it is easier to use existing ones than to create new ones. For example, in E3SM, there was not a data type to transfer data between river and land. Instead, developers use the data type designed for atmosphere and land to do the job. While it is ok to do so, it added unnecessary confusion for future development a…

Preparing graphics for journal publication is an important step before we submit the manuscript. And sometimes this process is not as smooth as we expected. There are several problems we often encounter: We generally generate more than enough figures and in the end, we only need a few;We also use different format for different purposes. For example, we use jpg/png for debugging. And we use svg/postscript for high quality production. A conversion is usually required.Journals usually prefer 600dpi high resolution figures. So postscript format might be the best option.Indexing is important for final upload.Subplot makes it even complicated.We use more than one tools as well. I use IDL/Python for plotting, but I also use GIMP/Snagit/Inkscape for some processes. Keep the process consistent is not easy. So maybe we need a clear road map so we won’t get lost easily. Here are my plans: Produce postscript/svg when possible using DrawIO/Python/IDL;If we need subplot, produce them simultaneously;…

Discretization by definition from Wikipedia: In applied mathematics, discretization is the process of transferring continuous functions, models, variables, and equations into discrete counterparts. This process is usually carried out as a first step toward making them suitable for numerical evaluation and implementation on digital computers. Now we add “spatial” to the term. The first intuitive definition is the discretization of functions in the spatial domain. There are two elements in this description: functions and spatial domain. For functions, we often refer to integral or ODEs/PDEs in numerical simulations. If these functions involve with gradient information, then they depend on spatial domain, which is how gradient is calculated. For spatial domain, we often refer to mesh or grid. And mesh can generally be classified into structured and unstructured grid. In practice, we have spent great effects on both aspects of the spatial discretization: mesh and corresponding function s…

Recently I asked a question on the GIS Exchange site:
https://gis.stackexchange.com/questions/315910/quantitatively-evaluating-quality-of-watershed-delineation-stream-line-results

I also asked the question on Research Gate:
https://www.researchgate.net/post/How_to_quantitatively_evaluate_the_quality_of_the_watershed_delineation_stream_line_results

The reason is that we have developed a watershed delineation model and we need to evaluate whether our model performs better or not than the previous method.

So we set out trying to find ways to evaluate the results.
The first thing as a watershed hydrologist will usually do is to look at the stream segments. If they match up with actual stream lines then it means the model is not bad.

However, both our method and the previous method can produce similar stream segment results. The the question is how can we say which one is better than the other one.

So we did some research online, and most publications used visual results as proof. Basically,…