[Developers] Control files and basic MCMC

John Sibert sibert at hawaii.edu
Fri Jan 17 16:25:11 PST 2014


Hi Arni and Dave and all,
Thanks for taking this up. Believe it or not, I have been trolling my email.

Personally, I think it is preferable not to separate control files from 
the data file. If you keep all the information together in one file, 
there is less need to remember which control file goes with which model 
run. Arni's pella.tpl example, it would be easy to simply append the 
control information to the dat file and OT change the input file name. IMHO.

I have been fooling around with xml files to take care of this sort of 
thing, and I think it is a good option, particularly for large models. I 
tried to demonstrate it in Seattle last year, but everything sort of 
went south. I took it up again recently and implemented an example 
starting from Arni's pella.tpl example. It is available on GIT.

git clone https://github.com/johnrsibert/ADMB_XML.git ADMB_XML

should get the whole mess for you. It uses a variant of Steve Martell's 
Makefile and builds and runs pella-xml correctly on linux with gcc 4.8.

Dave's recent additions to the lex and his suggestion about 
allocate(...) functions demonstrate how to incorporate variables defined 
as xml nodes into an ADMB app.

Some feedback might encourage me to take the next steps.

Cheers,
John


John Sibert
Emeritus Researcher, SOEST
University of Hawaii at Manoa
Honolulu HI (GMT-10)
808-294-3842

Visit the ADMB project http://admb-project.org/

On 01/13/2014 01:55 PM, dave fournier wrote:
> On 14-01-10 12:00 PM, Arni Magnusson wrote:
>
> I  added a bit of code to admb to do more or less what you want. Read 
> the txt file.
>
>     Dave
>
>> Happy new year to you, core developers!
>>
>> As Johnoel mentions, there is a wishlist item #11 in the Reykjavik 
>> Workshop Report that says:
>>
>> "Flag/switch class Simplify the use of control and MCMC files, 
>> perhaps MFCL-like object capability"
>>
>> This wishlist item is really about two things:
>>
>> ---
>>
>> (1) Sometimes we want to make ADMB applications general and 
>> user-friendly. By user-friendly, I don't mean beginner-friendly, but 
>> an efficient interface for running a variety of related models 
>> without recompiling. Fixing parameters and setting bounds, phases, 
>> and initial values, and various model-specific settings. This is 
>> sometimes done inside the main data file and sometimes in a separate 
>> control file.
>>
>> Take http://www.hafro.is/~arnima/pella/pella.tpl for example. The 
>> data and parameter sections are rather convoluted, in order to 
>> provide a PLUI (phase,lower,upper,init) interface for controlling the 
>> parameter estimation.
>>
>> Of course the exact implementation will vary from model to model. But 
>> writing the PLUI code feels unnecessarily clunky and repetitive. The 
>> code for switching to the control file is rather ugly, and and so is 
>> the code to set the parameter phases, bounds and inits. Perhaps these 
>> tasks are so common and so useful that we can provide some new 
>> functionality to make them easier for the ADMB programmer.
>>
>> This example is a tiny model with very few parameters. The importance 
>> of this wishlist item becomes greater with dozens of parameters.
>>
>> ---
>>
>> (2) MCMC is an important feature of ADMB. I like telling potential 
>> and new users that it's a piece of cake to run MCMC for any ADMB 
>> model: you basically just type mymodel -mcmc.
>>
>> Well, sort of.
>>
>> The http://www.hafro.is/~arnima/pella/pella.tpl example shows a 
>> common approach. First we have if(mceval_phase()) write_mcmc(); and 
>> later we have FUNCTION write_mcmc, with a long workaround to put a 
>> header for each column in the MCMC output.
>>
>> Wouldn't it be cool if the user could actually type mymodel -mcmc 
>> without all that stuff, and get a text file with column headers, 
>> ready to plot. For the most advanced users, the PSV file is just 
>> that, but for the majority of users that's not a very intuitive or 
>> accessible format. Again, a task that is so common and so useful 
>> could be made easier to use.
>>
>> A related idea is an MCMC_SECTION with a stream object that's ready 
>> to use, mcmc<<"blah"<<..., much like the report stream object in the 
>> REPORT_SECTION.
>>
>> ---
>>
>> As you can tell, I'm interested in both of these wishlist items. They 
>> may not be top priority, but potential areas where ADMB could be a 
>> bit smoother around the edges. We can revisit them at the next 
>> workshop, to decide whether and how some of this could be done. We 
>> did not look at this at the Reykjavik workshop, but included it in 
>> the report as a reminder of a discussion item after the workshop.
>>
>> All the best,
>>
>> Arni
>>
>>
>>
>> On Fri, 10 Jan 2014, Johnoel Ancheta wrote:
>>
>>> Hi all,
>>>
>>> Happy New Years.
>>>
>>> I looked over the workshop report and noticed a priority task 
>>> "Flag/Switch class to simplify the use of control and MCMC files..."
>>>
>>> It says someone is working on this, but did not say who?
>>>
>>> Johnoel
>>>
>> _______________________________________________
>> Developers mailing list
>> Developers at admb-project.org
>> http://lists.admb-project.org/mailman/listinfo/developers
>>
>
>
>
> _______________________________________________
> Developers mailing list
> Developers at admb-project.org
> http://lists.admb-project.org/mailman/listinfo/developers



More information about the Developers mailing list