This is the first version of CAPack, a convective analysis pack for DAWS, containing most of the convective scripts posted so far. If anyone has any problems with the code they posted being included, please let me know, and I will delete the offending code and replace with the exact same thing, because there are only so many ways to do some of this stuff with the analysis scripting at it's current level...

No, seriously, my thanks to everyone that posted analysis for these scripts, and for the people who had pieces of their script grabbed at random. If you recognise your code, the community thanks you, and your name for the credits would be welcomed, should we ever get any credits.. !

Thing the First, as with all scripts, I collated this for me, not for you, but if you can do something with this for your purposes, good.

Thing the Second, I know the retrievals in each script are unnecessary, that's why they are hashed... sometimes it's useful to have a demand script that does everything when you need it. Hence they remain because they can be useful.

Thing the Third, if you don't like the colours, layouts, gradations, etc, change them.. don't (necessarily) feel the need to tell me, just do what you want with them. Although ideas for feasible products and nice colour schemes are useful.

Thing the Fourth, the paths are almost certainly wrong for your system, and it's unlikely your map is called whatever.dmf. Adjust accordingly.

Thing the Fifth, Yes, I know there are 2 EXPORT lines. This works for me, because I keep a local archive and also push to a mounted network device. If this is not what you do, you know where the # key is...

Thing the Sixth, depending on the speed of your computer, you may want to adjust the schedule accordingly.

Thing the Seventh, if you're new to scripting there are examples in this pack of some of the more interesting features of DAWS, such as the very useful variable substitutions in the press_levels script. Work through them, and I guess you should have a pretty good grounding in the basics, because a lot of the guts of the analysis has been jointly written by the guys in the forum who seem to have the best handle on the scripting language.

Thing the Eighth, I thought it was self-evident that each
BEGIN <filename>
END <filename>
stanza needs to be pasted into a file named <filename>, without the stanza delimiters, but that's because I spend my time with other geeks and non-linear types who are used to things like this. My apologies. Now it should be obvious.

OK, that's it for now. More to come, currently working on LI, SWEAT, CAPE (hahahahahah...), Delta ThetaE, LLShear, DLShear, BRNShear,
SRH, ALSRW, and from those we can define EHI, BRN, VGP and SCCI. Will let y'all know.

Enjoy, report bugs with fixes rather than as statements of fact...

dryline

PS
Tim...

PLEASE READ THIS!

Is there any chance of a keyword for calculating CAPE as a program variable, rather than attempting to integrate manually? Any other parameters keyworded in future releases? I don't want to waste time with this if it will all be replaced with a single command in future versions.. if, on the other hand, that's a way out on the roadmap, I'm more than happy to keep fiddling with this pack.. would just be good to know, eh?

It's not a speed or data issue, or maybe it's both from a generic context.

A) Not one big script because one big script doesn't leave a hell of a lot of flexibility. A secondary goal here was to apply a standard semantic syntax & format across multiple scripts, because I intend to have an ass-load (technical term) of scripts, and then managing one big one becomes.. stressful. Also, seasonal variations will have a bearing on which parameters one is interested in... this way it's just a scheduler line to edit instead of going on a hash-fest in the code.

B) Some of the analyses take longer than others, for example the precip scripts call a map redraw because the transparency of fills isn't too good, and that takes a ridiculously long time on my P4 3.4Ghz crunch box. So I played safe, given that some machines will be faster than mine, but most will be slower.

C) Data is ingested every **50, to provide more complete synoptic/buoy/upper air coverage as available, and an hourly metar retrieval for nowcasts. I use the scripts to produce regular output, but I also call on-demand scripts when I want, and this way the ingested data is always relatively fresh for on-demand production.

PS, just thought of another reason.. as individual scripts, it's much easier to execute an individual analysis to use like extended analysis menu entries... ie, just run the appropriate script to produce the individual product, or to reissue a product that required late GTS data to correct anomalies.

I fully agree with you. That’s why I put a wish on Post requests for Digital Atmosphere V1.2 work on Jun 02, 2005 to add a function where you can call another script file: CALL, filename, where filename is a valid script name.

In relation to your comments:
A)In this case the 9 lines in your scheduler can be 9 lines in 1 script. In the scheduler you have to add just one line. I think that changing such a main script is even easier than changing a scheduler-script.
B)No problems about running time: the scripts will be executed in sequence (if the CALL-command is programmed in this way).
C)The ingest can be a separate script.
PS) I often use a script instead of a menu-command.

I recently downloaded this huge script, did the modifications for my use, and ran it. But all it does when I run it is scroll rapidly to the end. Old farts like me don't get into the writing of these scripts, so could someone please tell me how to run this?

It's not a big long script, it's a bunch of scripts indicated by BEGIN and END delimiters. Each script should be in a separate file, with the appropriate name.

The schedule should be entered in to your scheduler, and that should be that.

At the scheduled time, the scheduled script will run and produce the appropriate output.

If you're well aware of what I just said, then check your paths, etc.. something local to your system is misconfigured. Also, the structure for the output files must be constructed manually, because DA doesn't seem to create directories on the fly.

Hope that helps, if not paste up your log output when you run it.

Cheers,
--dryline

PS
Oops. Just realised I blindly assumed people would get that it's multiple scripts.. will edit original post to make this more clear. That's what you get for hanging out with coders all the time....

Let me know whether it works now, and let me know what you think of the idea... I hope to produce "standardised" (hah) scripts for most of the indices & derivatives as the scripting language grows in scale & capabilities to allow them. Hopefully other people will contribute the scripts they've written and not posted yet, and we can build a community toolset if nothing else.

I will do that! I can't wait for other parameters such as cape, lifted index,
ehi, and sweat, etc. The script language would grow if we could get our programmer in gear with some program updates. This is just insane that we have had no support for several months. I realize Tim was busy, and I'm not faulting him for that, but you have to admit it has been a long time without support or updates.

Anyway, not much weather around here today, but a warm front will bring more potential severe storms to us Sunday (tomorrow), then back into the hot and humid (soup) weather again

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum