Repository navigation
Ideas for KPP 4.0.0 #43
Description
Activity
Use ICNTRL in tau_leap and gillespie integrators
add Python and Julia as new languages to KPP
Have the Fortran90 code create a derived type with global variables
27 remaining items
Very minor and very esoteric feature, "empty" products in reactions
CAM-chem uses a similar feature for hard coding some artificial sinks into the mechanism.
e.g.,SF6 + hv = sinkorsoa + hv =. Tried building a mechanism with empty products and it throws a syntax error (as expected) withMisplaced ';'Probably could just use one of the DEFFIX species as product to work around this but just wanted to put it here in case there was further interest...
For products you don't care about, you can use the pre-defined dummy
species PROD, e.g.:SF6 + hv = PRODhttps://kpp.readthedocs.io/en/stable/using_kpp/04_input_for_kpp.html#equations
Thanks @RolfSander! I should've looked closely at the documentation first, my bad 😅
We should update obsolete fortran code, e.g., arithmetic IF
statements. The gfortran compiler already complains about this. Inutil/blas.f90, we currently have:IF (incX .EQ. incY) IF (incX-1) 5,20,60Now that
#TRANSPORTis deleted, I had a look at other rarely used
options. I noticed that there is a#WRITE_OPTcommand which isn't even
mentioned in our readthedocs manual. When activated, it calls
WriteOptions()indebug.c. It creates logging output which is nice
but redundant. We already have the same output inGenerateLog()in
gen.c.@yantosca: Should we delete
#WRITE_OPT?Hi @RolfSander, thanks for checking the old options. I think we can delete #WRITE_OPT. I'm not sure it was in the PDF manual, since that's what I took as the starting point for the RTD manual.
I just pushed PR #88 to remove LUMP. I can make another PR to remove #WRITE_OPT plus any other options that may no longer be used.
I don't think that
#WRITE_OPThas ever been in any KPP manual. Yes,
let's delete it.There are 3 similar options:
WRITE_ATM,WRITE_SPCand
WRITE_MAT. They also create potentially interesting output for
debugging. Unlike#WRITE_OPT, they are not duplicated elsewhere, thus
we may want to keep them. If we keep them, we could mention them in the
RTD manual.While I'm looking at these options, I decided to check all of them.
Here's what I've found:-
I think these can be deleted:
#DEFRAD#SPARSEDATA(scanner.c says that it is deprecated)#USE(scanner.c says that it is deprecated)#USES(seems to occur only in *.el)
-
#AUTOREDUCEisn't mentioned in the manual yet. -
#DECLAREis missing in*.el -
#FAMILIESappears twice in*.el -
For these, I have no idea:
#INITIALIZE#RUN#XGRID#YGRID#ZGRID
-
Thanks @RolfSander. I would keep the
#WRITE_{ATM,SPC_MAT}options for now. We can get rid of the others. I'll also add a note about#AUTOREDUCEdocumentation (based on @jimmielin's paper).It looks like the
#INITIALIZE, etc. might have been from running KPP as a model on a 3-D grid. I think we can also let those go.OK, sounds good. Let me know if there's anything I can do...
I forgot to mention
#SETRAD. Like#DEFRAD, it is also obsolete.Reacted by Bob YantoscaI suggest to enlarge some limits so that the complete MCM can be used. Increasing
MAX_NO_OF_LINESshould not cause any problems. RegardingMAX_EQN, we need to check if the new value is okay for all machines (except, of course, for those machines which already have to use a smaller value). You can find my first tests in the mcm branch.I suggest to add a
#DEBUGcommand. When set toON, KPP should create a log file with lots of information.Dear Professor Rolf Sander,
I hope this message finds you well. I am a beginner, currently a second-year Master's student in Atmospheric Science. Based on the KPP website example, I understand that running a box model requires four initial files: eqn, spc, dev, and a KPP file. However, in the MCM example you provided, I only seem to see settings for the initial model parameters in the driver_mcm document. After following the instructions in the README and running the model, I found that the mcm.exe did not output any results, which left me quite confused. Could you please provide more details on this issue? If possible, feel free to contact me via email at 1142331256@qq.com. Additionally, my programming skills are limited to Python.
Thank you very much for your time and help.
Best regards,
XinJie Liu
Add your ideas for KPP 4.0.0 here. Everything we don't have the time to work on now but may be a nice addition in the future...
Items yet to be done
Use ICNTRL in tau_leap and gillespie integrators.
Add RODAS3.1 coefficients to Rosenbrock integrators
Add Python (wrapper) and Julia as new languages to KPP.
Have the Fortran90 code create a derived type with global variables.
(See [FEATURE REQUEST] Save KPP global variables into a derived type object #11)
Formal uncertainty quantification and propagation through an integration step.
Add #DEBUG command
Write input file checker,
(See Input file checker #95)
Items recently completed
Replace all BLAS/LAPACK functions (WAXPY, WSCAL, etc.) in integrator files
(See Replace BLAS functions w/ pure F90 code in integrators #142 and Replace BLAS function WDOT with the Fortran DOT_PRODUCT intrinsic function #143)
Update obsolete fortran code, e.g., arithmetic IF statements
(See Replace BLAS function WDOT with the Fortran DOT_PRODUCT intrinsic function #143)
Delete
#WRITE_OPTandWriteOptions()in debug.c.(See Remove several more obsolete KPP commands #89)
Delete
#LUMP?(See Remove obsolete #LUMP command (and related variables) #88)
Delete
#TRANSPORTand#TRANSPORTALL(See Remove obsolete #TRANSPORT and #TRANSPORTALL commands #87)
Enlarge some limits so that the complete MCM can be used
(See Fixes to allow using the full MCM #100)
Use
Yinstead ofCinUpdate_RCONST()(See Add code from #INLINE F90_RCONST_USE at the top of the UPDATE_RCONST subroutine #120 and Add inlined code in the #INLINE F90_RCONST_USE block to the Update_Photo routine #125)
Migrate C-I tests from Azure Dev Pipelines to GitHub actions
(See Migrate C-I tests from Azure Dev Pipelines to GitHub actions #138)