This is part of the labels / documentation for <a href='http://jcm.chooseclimate.org'>Java Climate Model</a><hr/>

#viewparams		¨oldJCM4		§Old JCM4 tool, not in JCM5
To export a list of all changed parameters, try saving a @setup

#viewdata		¨oldlink		§£>datable

#notepad		¨oldJCM4		§Old JCM4 tool, not in JCM5. 
Similar functions in JCM5 provided by:
 @scripts, @sysout

#debug		¨oldJCM4		§Receive debugging info (erros and calculation info from the model) in this notepad. You can also get performance info -see @loop, and query state and interactions

#script		¨oldJCM4		§Run the script in this notepad. You can use this both for sophisticated batch calculations, and for checking/adjusting one parameter at a time, in conjunction with debug. See @scripting

#stop		¨oldJCM4		§Stop the script!

#clear		¨oldJCM4		§Clear this panel (and any script it contains)

#autodoc		¨oldJCM4 addJCM5		§Makes JCM documentation.

#labinf		¨oldJCM4		§This class provides labels, pop-up info and documentation, interpreting a text file loaded for the specified @languagemenu.<li>see @labdoc

#labdoc		¨oldJCM4		§About JCM Labels/ Documentation Structure: 

JCM documentation changes dynamically, responding to changing @language, @complexity, and @filters.  Each  @package,  @module, @qtset and @param describes its contents and state by examining its own java code, also reflecting  varying @interactions between components. 

So although the documentation looks like static web pages, it is actually created on demand by joining together many small sections of text. 

In JCM4 there were about 50,000 words of labels+documentation  (in english), covering about 700 seperate items, including about 1500 hyperlinks.

For more information see<ul>
<li> @docview
<li> @editdoc
<li> @translation
<li> @acknowtranslate
</ul>(and for experts)<ul>
<li> @labelcode
<li>@labdocfiles
<li>@labdoctable
<li>@jcm.gui.doc 
%%(package of java code which handles the labels and documentation)%%
</ul>

#labdocintro		¨oldJCM4		§All of JCM's plot labels, pop up information, and documentation are now stored in the same plain-text format,
  There are currently about 50,000 words of labels+documentation  (in english ), covering about 700 seperate items.
  Sections of text can be re-used in several different contexts, and hyperlinks are easy to write and check (there are about 1500).
  <hr>
  €€cogs The java code which handles labels and documentation can be found from @autodoc, @labinf, @txt, @showwebpage (all within @tls package).
  €€adju The system can also be used without a web browser - see @startjcmswing
  €€adju The documentation can be easily searched or indexed (see @docsearch, @doclist)

#labdoctrans		¨oldJCM4		§£>translation

#labdocmodel		¨delete		§£>editdoc

#names		¨oldJCM4		§£>labelcode

#labdocfiles		¨oldJCM4		§Although the documentation is displayed as HTML, it is constructed on demand from text files. 

€€cogs These files are stored in the package labdoc.jar. 
€€cogs Only short english labels (lab_en.txt) are  inside JCM5.jar, (in order that the model may get started quickly while the labdoc.jar package is still downloading across the web)

€€cogs The labels/documentation are split into many separate files so that they are only loaded on demand, depending on the chosen language and topic. 

€€cogs  All labels which may be used within the graphical interface, plus titles of documentation sections, are stored in files lab_XX.txt  (where XX is a language code). 
€€cogs Changes made by the wiki @editdoc system are saved separately, in a folder **labdocchanges**. Eventually, these changes should be blended into the main jar file for distribution ( @contact, see also @translation)

#scripting		¨oldJCM4		§To be updated
£>scripts
£<scriptingold

#scriptintro		¨oldJCM4		§JCM scripting code is designed to serve several functions.   <li>set the value of any paremeter you can adjust the mouse, and also many other public variables within JCM. This is useful for quick ad-hoc experiments and debugging, using a @notepad or System.input (see @scriptrun)  <li>run automatic demonstrations from web pages -explaining how to use JCM (see @howto), or illustrating specific points about the policy options or scientific uncertainties  <li>perform loops, mathematical operations etc., including creation of variables, like any simple computer language. This enables batch calculations and iterations in problem-solving frameworks, to be run without having to compile java or even to restart the model. For example, see @stabtemp2cscript  <li>connect multiple users to share the same model world across the web. The potential has already been demonstrated in earlier versions, but it is not yet implemented in the current version (see @remotecontrol).   <li>some other functions: make a new plot (see @blankplot), create and display a web page (see @showwebpage), load and save data, etc.  (under development).  <li>if you envisage another useful function, please tell me (see @contact)

#scriptlang		¨oldJCM4		§<li>Interpreted scripting languages, like Javascript, Perl, Basic, or Python, are usually easier to write, read, and adjust quickly  <li>Compiled languages like Java (see @aboutjava), C++, or Fortran usually run much faster, and are more reliable since the compilation process checks for errors.

  It makes sense, therefore, to use compiled Java for the computationally intensive, frequently used, core scientific modules and graph-plotting routines, while using an interpreted text script to direct specific applications such as batch-calculations or automatic demonstrations.

  Bridges between Java and several existing scripting-languages have already been built, however adding such packages to JCM would make it too large to load rapidly on the web. So a simple custom script interpreter (as described below) was developed for JCM.

  However parsing a script is not a trivial task, even with only a small set of functions, so for more complex applications it might be better to adapt an existing interpreter. Javascript might be a good choice as it is already built into most web browsers and has a (deceptively) similar syntax to Java. On the other hand, the script should also work when JCM is run as a standalone application: this is important because security restrictions prevent data files of model results from being saved from a web browser! 'Rhino' (www.mozilla.org/rhino) project may provide a solution to this, which will be investigated later. Another option could be 'Jython' (www.jython.org), which has also been demonstrated to work efficiently within applets.

#scriptrun		¨oldJCM4		§<li>You can test a simple JCM script using a @notepad (choose from any @plotmenu). Write the script there, or paste it in from a text file (examples are in jcm/script directory), and press the @script button. It may help to open another notepad and press the @debug button, to show any output from the script, as well as any routine progress info or error messages.  <li>JCM Scripts can also be called from webpages, using javascript instructions <script>jcm.playfile('script/scriptname.txt');</script> (to load an existing script file) or <script>jcm.playi('scriptstring');</script> to run a short script defined within the string.
  %%note, the wepage header must also include <script src=jcmjs.js></script>%%  <li>Scripts can be included in documentation items using a simple tag (see <a href="../labels/syntax.txt" target="txt">syntax.txt</a> file) - this also puts buttons in the web page as follows £!dummy .  <li>It is envisaged that a method to run JCM with a script from the command-line will be developed (together with a method to save the resulting data)  <li>(for java experts!) It is also possible to send a short script to JCM using Java System.input, if you start  JCM from a tool  (e.g. a command-prompt console) which has a text input facility

#scriptcode		¨oldJCM4		§The documentation page explaining the syntax of JCM scripting code can now be found in the jcm/script directory of the package (see @download). <a target='_new' href='../script/scriptcodesyntax.html'>Here is a link to scriptcodesyntax.html</a>

#scriptparam		¨oldJCM4		§Some adjustable parameters in JCM may be used in scripting, which do not have graphical controls:  <li>backred, backgreen, backblue : set background color components (range 0-255) (in @mainapp)  <li>loopinfo : adds performance info to standard output (time spent calculating each module) (in @loop)  <li>scriptmode : sets one of three modes for response to adjustment of parameters (in @param)
  - demo : for automatic demonstrations, in which menus and control info pops up, as if the user passed a mouse over them
  - direct : model recalculates immediately, but no popup info (this is the default)
  - delay : no recalculation or replotting until next "run" instruction: this could be used to change several parameters at once more efficiently, or to recreate a snapshot of the model.

#player		¨dem		§Runs a script  code: See @scripting

#recorder		¨oldJCM4		§This records JCM scripts, complementing @player. Recorder and Player may run in parallel threads for live connection between two JCMs across the web. Thsi feature was working in 2001, but has not yet been reinstated with new scripting code.

#scriptlist		¨dem		§£!timescalescript
  £!emitdeclinescript
  £!backcoltempscript
  Stabilisation under Uncertainty
  £!stabtemp2cscript
  £!stabconc500script
  £!stabuncert25script
  Probabalistic Scripts (slow!)
  £!carbonprobscript
  £!carbonprobscriptinv
  How Use Demos
  £!howuco2tempdemo
  £!howuemitseademo
  £!howulabelsdemo
  £!howuscalesdemo
  Experimental
  £!testscript
  £!testscriptjs

#emitdeclinescript		¨dem		§This script demonstrates how array values within JCM java code can be queried and reset dynamically
  However as you can see, the interpreter is rather slow (partly due to java reflection being slow)
  £!emitdeclinescript
  See also @scripting

#remotecontrol		¨fut		§At Grid-Arendal in 2001 a system was developed whereby several users may share the same model by "remote control" across the internet, with a view towards developing JCM for @dialogue. This system worked very efficiently, because only the changing model @param needed to be sent across the internet, the model itself and the graphics are calculated locally. However synchronisation between people was found to be a challenge - how do you explain to a user who may be the other side of the world, why you are moving specific arrow-controls about on their screen? So an alternative approach was explored- to record a  demonstration or snapshot  of model events to illustrate a point, accompanied by textual explanation, which could be posted on the website for viewing by others later. This may have applications in organised group dialogues or @teaching.

It is hoped to revive the record/playback feature: see @scripting

#doclistinfo		¨oldJCM4 addJCM5		§%%This list, is generated automatically using the currently selected @language. It includes labels as well as documentation pages
See also @docsearch .%%

#searchresults		¨oldJCM4		§%%Search uses currently selected language. It may take a little time.%%
  %%€€cogs panel documentation pages only include curves and controls which are currently visible %%   

    %%€€cogs (see @labdoc, @labinf for method)%%

#txt		¨oldJCM4		§This class contains some methods for parsing text strings -it is mainly used by @labinf, @autodoc, @player

#sysin		¨oldJCM4		§To capture script instructions from System.input (for experts!)

#fileio		¨oldJCM4		§This class contains some methods for loading and saving text files (loading either from the web or locally).

#showwebpage		¨oldJCM4		§This class makes a web page appear in a certain frame, and stores a text string ("info") which may then be collected by javascript within that page. It is used by @autodoc and @player. See also @helpmode.

#sort		¨oldJCM4		§Quicksort tool - sorting the labels/doc sections makes the lookup faster. Also used for search-doc and list-doc

#searchawot		¨old		§%%€€adju try £`anywords to get more results, £`onlytitles to get less. %%