Quantum Forest logs are written by Luis A. Apiolaza in Christchurch, New Zealand and powered by TextPattern.

Topics

Non-blog (Wiki)

Somewhere else

I do run ASReml in a mac
Published Thursday January 18, 2007 · Permalink

For quantitative geneticists and breeders out there: ASReml runs OK in any mac with Intel processor and Parallels. You can find some comments on using it in the ASReml Cookbook.

Incidentally, SAS works OK in a mac using Parallels too. However, I am enjoying R a lot more.

אאא

Current obsessions
Published Tuesday March 21, 2006 · Permalink

I have slightly changed the focus of my attention during the last month or so. My current obsessions are:

There are a few bits and pieces that do not fall in these two broad areas, but they will converge pretty soon.

Family-wise

Working with Marcela and Orlando in the veggie patch. I have never had much of a green thumb, but I am really trying. We sowed coriander, parsley and chervil, and planted bok choi, onions, dill, lemon balm and capsicum. Apart from the capsicum seedlings that are struggling (a drainage problem is my guess) everything is doing fine.

Marcela and Orlando checking worm farm

Marcela’s worm farm is the old-new addition. We used to have a worm farm in Australia, but due to quarantine issues, we decided to leave it there. So we needed to get a new one plus order the first batch of worms by mail.

אאא

LIDAR ground truthing
Published Tuesday August 2, 2005 · Permalink

In the previous post I was hopeful that our simple LIDAR data processing would be able to locate the trees, but I did not have any evidence to confirm that what we saw in the computer was not a fluke.

After postponing field work due to bad weather, last Thursday we had a field crew assessing six GPS located plots. Today David overlayed the plot data, after differentially correcting it, and the position of the trees estimated with LIDAR and ta-da! the trees pretty much match (picture coming soon). There are some random differences (of up to 2 meters) in position, but considering that the stem is not necessarily under the top of the tree and that there was quite a bit of data processing and smoothing, the results seem to be extremely promising.

We now need to formally estimate the association between positions, explain any errors of detection (trees in the ground but missing in LIDAR or vice versa) and prepare a short report.

Some times work is sweet, particularly when reality and models match one another.

אאא

First look at LIDAR
Published Friday July 22, 2005 · Permalink

This has been a very busy and intense week. Deviations from routine are—at least most of the time—welcome, and particularly so in this case.

LIDAR is a fascinating technology, which until last week I always thought to be very overrated. People were always presenting pretty pictures, but nothing really useful. Last Friday we had a meeting where we discussed using LIDAR, aerophotography, Quickbird and field measurements in some native forest to obtain stand level attributes and make thinning decisions. Finally a practical application!

On Monday David, Jamie and I got the text files (with x, y and z coordinates, and intensity). The files were huge, with a total of 150,000 points to describe 10 ha. I first read them with Splus and R, which clearly didn’t like much the size of the matrices. Maybe Splus 7 developer (with the new pipeline architecture) works better, but I do not have a copy yet.

At the same time, I imported the data into MayaVi (which uses VTK) using an adaptation of this Python script and producing the following visualisation to get a feeling of the site. It is easy to interact with the picture, and one can see the road and the difference between old trees and regeneration. However, it is still pretty useless.

LIDAR data in MayaVi

Trying to work with individual (non-grid) points proved to be fruitless. The size of the problem is huge, and trying to use any spatial statistics contained in the R module spatstat was hopeless. Trying to apply anything that requires a large distance matrix (150,000×150,000) is guaranteed failure.

Meanwhile, Jamie helped David to obtain crown and terrain surfaces using Kriging in SAGA.

title=

After transforming them in grids, and substracting them to get ‘true’ tree heights, David and I came up with a naive (slow but apparently effective) way of finding the top of the trees. After a few problems with the implementation and Simon’s help using a SQL query in Manifold, we were able to identify the tops and their respective heights. From there to a diameter/height and volume equations there is a small step.

Top of trees in small section

Now we need to move to ground truthing and thinning strategies.

PS. 2005-08-01. We are processing data from ground truthing and our work is looking even more promising.

אאא

Alphabet soup: R, S and SAS
Published Friday August 20, 2004 · Permalink

After a series of post on environmental issues, it is good to come back to software and statistics. I am a user of many different statistical packages: Splus and Genstat for general statistics, PASS for power calculations and ASReml for generalised linear mixed models (GLMM, particularly for quantitative genetics analyses).

While I consider that PASS and ASReml are pretty good value for money—especially the latter—I sometimes question my choice of generic software. Until 1996 I used to be a ‘heavy duty’ SAS user (at least of base, stat, iml and graph). Some of the many drawbacks of SAS were its low quality graphics, low speed for large analyses and its price (near AU$10,000 a year for the modules I used for work). SAS is also quite monolithic and usually is much slower on the adoption of new analytical techniques. On the other hand, SAS database facilities are quite good and it can cope with large analyses relatively well, albeit very slowly.

In 1996 I discovered ASReml (~AUD$1,500) and, given that most of my work was of the GLMM kind, I switched and never looked back. ASReml is lightning fast (orders of magnitude more than SAS) and it allows to implement very large analyses, enough for running a national genetic evaluation for forest trees.

Genstat is a good generic package, but the graphics have lower quality than Splus’s, the language is too Fortranian for my taste and the community of users is quite small. The small community makes discussion and implementation of new routines slower than in Splus, and gives the feeling of a ‘dead end’ from a language evolution point of view.

Splus is a terrific piece of software. However, buying it is around AU$4,500 and AU$1,000 per year of maintenance. This is still quite a bit of money, particularly for small businesses. This takes me to R, an open source implementation of S, without the fancy GUI but with the same analytical capabilities of Splus. If you are a ‘power user’ of Splus there are very good incentives to move to R; firstly, it is free and, secondly, you are already quite proficient on R, because the syntax is very similar. If you ask me, Splus is slowly pricing itself outside the small business market and many ‘power users’ of Splus, which rarely use its GUI, will not see any benefits on keeping paying for software licenses, because this time there is ‘almost a free lunch’. At work we are evaluating R for use by the biometricians and, maybe, by the more sophisticated researchers. Other researchers will still probably stay with Genstat, at least until R develops a decent GUI. But that time—if ever happens—we may decide to switch everybody to R.

אאא

   Older posts