[Developers] Running ADMB with separate exe and data dirs

Ben Bolker bbolker at gmail.com
Fri Nov 5 07:29:59 PDT 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  It would be worth taking a look at

VGAM
MCMCglmm
pscl
betareg

  packages -- these are some of the more flexible modeling packages
within R, and hence have had to extend the formula specification.  If we
can stand it, it probably makes sense to use the lme4 specification for
random effects.

  Ben

On 10-11-05 02:32 AM, dave fournier wrote:
> Hans Julius Skaug wrote:
> 
> Hi,
> 
> I would like to see more models.  I'm not sure how difficult it is for
> example to
> use the current R interface to produce a beta regression mixed model.
> 
> Also I would like to see the models able to accommodate crossed random
> effects as an option using the -shess option.
> 
> Also using more flexible parameterization of the  overdispersion in the
> NB models.
> Also ability to test for extra overdispersion in the NB via the mixture
> of NB's.
> 
> Other models such as 3PL IRT  and up to 5PL as in PK models.
> 
> All this is trivial (i.e. we already have the code) in ADMB. the difficulty
> is in the R glue.
> 
> There must be other models that could easily be implemented.
> 
>       Dave
>> Hi,
>>
>> What Arni says regarding glmmADMB is correct: the reason for doing things
>> in a temporary directory was to avoid too many output files
>> in the R working directory, but still being able to access the files
>> if needed.
>> The original idea was that users who find glmmADMB too limited would
>> proceed to become full ADMB users. That has not happened to much
>> extent yet. I am not sure what our philosophy for the package
>> is now. We may as well try to hide as much of the ADMB details as
>> possible.
>>
>> Hans
>>
>>  
>>> -----Original Message-----
>>> From: developers-bounces at admb-project.org
>>> [mailto:developers-bounces at admb-project.org] On Behalf Of Arni Magnusson
>>> Sent: Friday, November 05, 2010 2:09 AM
>>> To: Ben Bolker
>>> Cc: developers at admb-project.org
>>> Subject: [Developers] Running ADMB with separate exe and data dirs
>>>
>>> Hi all,
>>>
>>> Ben raises an interesting question, regarding the behavior of ADMB
>>> when running a model with the executable and data in separate
>>> directories.
>>>
>>> I think the reason the glmmADMB binaries are copied to the temporary
>>> directory before running them is because ADMB executable models
>>> create some "garbage", and R packages shouldn't create any garbage
>>> inside the R library tree. The same cleanliness might be required in
>>> other cases when the same executable is used on many input files -
>>> simulations or when embedding ADMB inside another application.
>>>
>>> I use the word "garbage" here for all output files except simple.cor,
>>> simple.par, and simple.std. Clearly, those garbage files do indeed
>>> have value for the modeller, e.g. when debugging a model or accessing
>>> precise numbers related to the estimation.
>>>
>>> So here are four experiments describing the behavior of ADMB 9.1,
>>> when running a model with the executable and data in separate
>>> directories. The 'exe' directory contains the simple executable and
>>> the 'data' directory contains simple.dat. One experiment involves a
>>> 'third' empty directory.
>>>
>>>    Experiment #1, from within exe:
>>>    simple -ind ~/data/simple.dat
>>>    => all results created in 'exe', and no files are added to 'data'
>>>
>>>    Experiment #2, from within data:
>>>    ~/exe/simple -ind simple.dat
>>>    => useful output in 'exe' and garbage in 'data'
>>>
>>>    Experiment #3, from within data:
>>>    ~/exe/simple -ind ~/data/simple.dat
>>>    => useful output in 'exe' and garbage in 'data'
>>>
>>>    Experiment #4, from within third:
>>>    ~/exe/simple -ind ~/data/simple.dat
>>>    => useful output in 'exe' and garbage in 'third'
>>>
>>> I guess what the user would expect is that in all four cases, all
>>> output files should appear in the same directory as the input data file.
>>>
>>> Johnoel, I vaguely remember some earlier discussion on this topic.
>>> Will the new ADMB release have different behavior from the above
>>> experiments?
>>>
>>> All the best,
>>>
>>> Arni
>>>
>>>
>>>
>>> On Thu, 4 Nov 2010, Ben Bolker wrote:
>>>
>>>    
>>>> I rearranged stuff a bit in glmmADMB and added the MacOS       
>>> binaries Dave    
>>>> sent; committed to R-forge.  The package passes R CMD check       
>>> for me (on    
>>>> Linux), and installs and runs the example(glmm.admb) OK on       
>>> MacOS.  I    
>>>> rearranged the structure in which the binaries are kept       
>>> slightly (there    
>>>> are now separate linux/windows/macos subdirectories). If       
>>> any of you has    
>>>> a Mac for testing, please give it a whirl -- or we can get       
>>> back to the    
>>>> MacOS users who have posted on admb-users and ask them to       
>>> try it out --    
>>>> or we can post to the list in general.
>>>>
>>>> Don't know what the difference is between the old binaries       
>>> on the otter    
>>>> research site (which give an 'illegal instruction' error       
>>> when I run them    
>>>> on MacOS X.6) and the new ones provided by Dave ...
>>>>
>>>> PS Hans, Arni -- can you tell me offhand why the binaries       
>>> are copied    
>>>> from their installed location to the temporary directory       
>>> before running    
>>>> them under Unix?  Do ADMB binaries have a separate concept       
>>> of "directory    
>>>> where I live" and "directory from which I was called"?
>>>>
>>>>   cheers
>>>>    Ben
>>>>
>>>>       
>>> _______________________________________________
>>> 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
>>
>>   
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzUFOcACgkQc5UpGjwzenNBNwCfVdbnzfbFZdB+J2rip+wrXpuk
dEEAn1RBQJWBwI4qu/2k3WwOiblrGWxI
=LjK4
-----END PGP SIGNATURE-----


More information about the Developers mailing list