I have two netcdf files: downwelling radiation named rsds.nc and confined radiation named rsns.nc. rsds.nc contains a variable named rsds and rsns.nc contains a variable named rsns. Now I would like to have the upwelling radiation rsus.nc by subtracting the variables within rsds.nc and rsns.nc, respectively.
I tried the following methods:
ncdiff rsds.nc rsns.nc rsus.nc
ncbo op_typ=diff rsds.nc rsns.nc rsus.nc
All of them produced a rsus.nc but the variable rsus, within this file is missing. Any idea of why this is so?
Two alternative CDO solutions.
The sledgehammer approach
The cdo sub command can do this on one line:
cdo sub rsds.nc rsns.nc rsus.nc
You will get the warning
cdo sub (Warning): Input streams have different parameters!
But you can ignore that. Note that you may want to change the variable name to something more appropriate, so you can do this on one line as:
cdo setname,rsus -sub rsds.nc rsns.nc rsus.nc
The expr approach
This just mimics the accepted answer but in cdo equivalent commands
cdo cat rsds.nc rsns.nc tmp.nc
cdo expr,"rsus=rsds-rsns" temp.nc rsus.nc
By the way, with all solutions on Thurs page you might want to use cdo chgattr or the nco equivalent to ensure the meta data is correct for your new field, especially if you intend to keep the files long term or pass them to other people.
As an alternative to #RichSignell's answer, you can combine variables into a single file and use ncap2 to perform the subtraction without renaming variables.
ncks -A rsns.nc rsds.nc
ncap2 -s 'rsus=(rsds-rsns)' rsds.nc rsus.nc
Only variables with the same name are operated on when you ncdiff two files. So one solution would be to simply rename the variable in one of the files so it is the same. For example, try this:
ncrename -v rsds,rsns rsds.nc
ncdiff rsds.nc rsns.nc rsus.nc
Related
I have two timeseries netcdf files with the same number of steps:
U.nc with variable name u10.
V.nc with variable name v10.
Now I want to add multiply U.nc with U.nc
similarily, V.nc with V.nc.
I also want to add U.nc with V.nc., the variables u10 and v10 should be added.
How can I do this?
A similar answer to Adrian Tompkins's above.
cdo -L -expr,'wind=sqrt(u10*u10+v10*v10)' -merge u.nc v.nc uv.nc wind.nc
This uses method chaining. Depending on how CDO was built, you may or may not need -L.
you can do it with CDO
Adding u with u:
cdo mul u.nc u.nc ubyu.nc
and
cdo ubyu.nc vbyv.nc usumv.nc
However it seems what you want to do is make the wind vector, for that you can merge the files and then use the expr operator
cdo merge u.nc v.nc uv.nc
cdo expr,'wind=sqrt(u10*u10+v10*v10)' uv.nc wind.nc
See the tutorial here for more details on the the expr operator
I'm having some preprocessing mishap while compiling a 3rd party library with g++.
I can see in -E output that a certain header wrapped with #ifndef SYMBOL is being bypassed. Apparently, that symbol has been defined somewhere else.
But I cannot see where because processed directives are not present in the -E output.
Is there a way to include them (as comments, probably)?
No, there is no standard way to get preprocessed directives as comments.
However, you could use g++ -C -E and the line numbers (output in lines starting with #) and the comments (which are then copied to the preprocessed form).
And you might also use the -H option (to get the included files)
The closest thing I found is the -d<chars> family of options:
-dM dumps all the macros that are defined
-dD shows where they are defined (dumps #define directives)
-dU shows where they are used (in place of #if(n)def, it outputs #define or #undef depending on whether the macro was defined)
Adding I to any of these also dumps #include directives.
The downside is only one of the three can be used at a time and they suppress normal output.
Another, less understandable downside is -dD and -dU do not include predefined macros.
I don’t understand the difference between:
set youtube=’https://youtube.com’
and
youtube=’https://youtube.com’
With the second one, I’m able to use it in the middle of a command, such as:
cygstart $youtube
and that works.
Why and how are these different? They both set variables?
And, when I don't use the word "set" I have to expand the variable using $?
Thanks.
The two commands are completely unrelated; set youtube='https://youtube.com' has nothing to do with $youtube. What it does is, it sets $1 to the whole string 'youtube=https://youtube.com'.
Per http://www.gnu.org/software/bash/manual/bashref.html#The-Set-Builtin, set is a shell builtin with three distinct purposes:
If you don't give it any options or arguments, it prints out all the existing shell variables and functions.
It has various options that let you change various properties of the shell. For example, set -C tells the shell that you don't want > to overwrite existing files (and that you instead want commands to fail if they would otherwise do that); and set +C tells the shell that never mind, you now want > to be able to overwrite files again.
Any arguments, other than options, replace the positional parameters ($1 and $2 and so on, as well as $# and $*).
Since set youtube='https://youtube.com' calls set with exactly one argument, namely youtube=https://youtube.com, it has the effect of setting the first positional parameter ($1) to youtube=https://youtube.com.
Note that youtube='https://youtube.com' is a somewhat misleading way to write youtube=https://youtube.com; the single-quotes aren't doing anything here (since the sole purpose of single-quotes is to escape whitespace and special characters, and https://youtube.com doesn't have any of these).
Consider the following:
SET(TEST_DIR, "test")
INSTALL(PROGRAMS scripts/foo.py DESTINATION ${TEST_DIR})
INSTALL(PROGRAMS scripts/foo.py DESTINATION #TEST_DIR#)
The first INSTALL command does not work. The second does. Why is that? What is the difference between those two? I have not found any reference to ## expansion except in the context of creation of configuration files. Everything else only uses ${} expansion.
UPDATE: OK, obvious bug in the above. My SET() command has an extraneous comma. Removing it, such that it looks like:
SET(TEST_DIR "test")
results in both ## and ${} expansions working. Still wondering (a) what is the meaning of ## as opposed to ${}, and why only the former worked with my incorrect SET() statement.
According to the documentation for the configure_file() command when configuring a file both the ${VAR} form and #VAR# form will be replaced VAR's value. Based on your experience above and some testing I did both forms are replaced when CMake evaluates your CMakeLists.txt, too. Since this is not documented I would recommend against using the #VAR# from in your CMakeLists.txt
Note that when using configure_file() you can restrict replacement to only the #VAR# form by using the #ONLY argument.
As far as I know, the #VAR# syntax is only used when replacing variables with the configure_file command.
Note that the configure_file command allows for an extra option #ONLY. Using it you can specify that only the #VAR#'s are replaced, but that the ${VAR}'s are kept.
As an example, this can be useful when generating e.g. a cmake-file which is later to be used with CMake again. E.g. when building your project, the #VAR# will be replaced when using configure_file. After you distributed your project and someone else uses the generated UseProject.cmake file, the ${VAR}$ entries will be replaced.
I need to know some basic information on the for command in batch scripts. One thing I want to know is why its %%variable instead of %variable%.
%A is for use on command lines only.
%%A is used when used in batch files.
The single-percent %a syntax indicates a local variable within a batch file.
The percent-bracketed %foo% represents the value of an environment variable named foo.
From ss64.com:
If you are using the FOR command at the command line rather than in a batch program, specify %parameter instead of %%parameter
So %%param is for batch scripts and %param is for live commands. Greg is right, %param% is a different kind of variable. The "variable" in the FOR command exists only that scope, while environment %variables% persist in a wider scope.