C[omp]ute
Welcome to my blog, which was once a mailing list of the same name and
is still generated by mail. Please reply via the "comment" links.
Always interested in offers/projects/new ideas. Eclectic experience in
fields like: numerical computing; Python web; Java enterprise;
functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile;
telecommute worldwide. CV;
email.
© 20062015 Andrew Cooke (site) / post authors (content).
Chinese Writer Hu Fayun
Permalink

Comment on this post
Previous Entries
For comments, see relevant pages (permalinks).
Apricot Jam
From:
andrew cooke <andrew@...>
Date:
Mon, 21 Nov 2016 14:37:12 0300
Fruit 2.5kg (after removing stones  bought 3kg)
Sugar (rubia) 1.25kg
Juice 1 lemon
5tsp (old) vanilla extract (at end)
Made 5.5 0.5kg jars
Halved fruit and included skins. Cooked until "superheated" and
catching n bottom pf pan. Still appeared quite runny. Initial taste
is quite tart (reduced sugar  previously using 2:3 instead of 1:2).
Early in cooking, foam overlfowed pan. After cleaning up, adding some
(olive) oil seemed to stop that.
Andrew
Permalink
Doxygen + Latex on CentOS 6
From:
andrew cooke <andrew@...>
Date:
Tue, 1 Nov 2016 10:55:37 0300
The following magic incantations were necessary to get Doxygen latex
output to convert to pdf using pdflatex on CentOS 6.8 (which does not
have luatex):
# increase by a factor of 10 the values of
# main_memory, pool_size and save_size
sudo emacs nw /usr/share/texmf/web2c/texmf.cnf
# don't know if this is really needed
sudo texhash
# this ends with an error, but appears to work anyway(?!)
sudo fmtutilsys all
Together they address the "TeX capacity exceeded, sorry" errors.
Andrew
Permalink
Modelling Bicycle Wheels
From:
andrew cooke <andrew@...>
Date:
Thu, 13 Oct 2016 10:50:46 0300
I'm trying to do some simple (2D, simplified physics) modelling of
bicycle wheels. Unfortunately, it's turning out to be harder than I
thought.
The immediate problem is that I am not able to find (efficiently and
reliably) the stable solution. It seems that my equations for forces
and energy are correct, because occasionally a solution converges.
The difficulty is "numerical" in some sense.
I can think of three problems:
 Local forces
I calculate the force at each "spoke hole" as the sum of three
components  the spoke (in tension, connected to the fixed hub), and
the two rim segments (in compression, spanning to adjacent holes).
The simplified physics assumes a "hinge" at each hole.
This sounds fairly reasonable (in particular, I have a Jobst quote
somewhere supporting the hinge model), except that it assumes that
the rim segment endpoints are in equilibrium. In fact there may be
net forces there (when not at equilibrium) which are "passed along"
and also affect the hole under examination.
I don't see any way to avoid this. It's the ugly compromise one
gets when finding a static solution to a system that would go
through some dynamic evolution. Ideally you would model the entire
dynamics. Instead, you iterate the static minimisation. But some
of the (GSL) minimisation routines I am using seem to handle this
poorly.
 Local movement
I describe the system as a collection of (x,y) coordinates of the
holes (spoke end points). So a simple physical action like
contracting the rim inwards in response to spoke tension involves
altering all the variables.
I am not sure this is a problem for methods that use a matrixbased
solution (since the solution can move multiple points), but it seems
like it could seriously affect simplex minimisation.
Instead, I could use some kind of Fourier scheme where zeroth order
is a constant radial shift, etc etc. The problem here is that it
seems to make calculating derivatives much more expensive (although
derivatives are not needed for simplex).
 Unstable collapse
The hinge model assumes that the rim segments always have an
internal (hub facing) angle less than 180 degrees. If this is
exceeded then the wheel becomes unstable and collapses.
This may be a source of instabilities in the solution when an
additional force is applied. It would be useful to have some kind
of minimisation that could easily detect this condition.
Given that I am currently stalled it seems like I have two options. I
can implement the Fourier based approach (second above) or try to do
some kind of customized solution "by hand".
A handrolled approach could deal with item 1 above by using an
iterative alorithm (quasidynamic). It could also handle the third
point if it used calculations tailored exactly to the configuration
used.
So I could calculate the approximate solution for each hole in
isolation as a pair of 1D roots (zero force perpendicular and parallel
to the chord from neighbouring holes). This would be quick and allow
detection of the instability. By moving the hole only a fraction of
the distance to the solution and then iterating the entire wheel I
would move towards a consistent solution.
Andrew
Permalink