My Blog

Teething Troubles: Responsive Menus in Hyde

So, after looking so nice on desktop and mobile, it turns out that dataonlygreater.com has some problems when it comes to ipads. I first noticed this on my Dad’s ipad, but there is also a neat online tool called Screenfly that will let you see your website using the resolution of many different devices. The results of looking at the Academic page using ipad resolutions were like this:

ipad view

Now Hyde is a fully resposive template for Jekyll, meaning that it should display well on all devices, by rearranging itself or modifying the text size. I did make one change to the base Hyde configuration, in this respect, changing a number of the “@media” CSS commands from

@media (min-width: 48em)

to

@media (min-width: 48em) and (min-height: 32em)

The main navigation is in the side menu, so the problem with the first command was that if the screen height was small, and the width was wide, the menu would be lost and you could not navigate the site any more. This was the only “flaw” I found in the stock Hyde template.

Rather than Hyde, the problem that has shown itself with the navigation buttons on ipads is of my own doing. These navigation buttons were one of the last additions I made before launching the site (perhaps that’s why I didn’t test it as well as I should have!) and are modifications of Code a Responsive Navigation Menu by Joshua Johnson. To make them fit into the responsiveness method of Hyde, which uses min-widths, I changed the CSS styles of the menus to this:

@media (min-width: 48em) {
	.navmenu.academic nav li a {
	    width: 31%;
	    font: 400 1.5rem 'Luckiest Guy', cursive;
	    margin: 4px;
	}
}

The problem here is that I have not been very sympathetic to the way that Hyde changes with increasing width. There are, in fact, 3 different stages once the sidebar is to the left, including a font size change and a margin size change. These changes occur at 54em and 64em, with the switch to the left sidebar starting at 48em. So, I needed to add more responsiveness in the navigation buttons to cope with these changes.

My solution then was to keep the stacked menu until the font size changes at 54em and then add two more font size changes in the menu buttons at “full-screen” (80em) and an intermediate stage (72em) where the font is becoming a bit lost in the button. So the new CSS looks like this:

@media (min-width: 58em) {
	.navmenu.academic nav li a {
	    width: 32%;
	    font: 400 0.7rem 'Luckiest Guy', cursive;
	}
	.navmenu.academic nav small {
	    font: 100 0.65rem Helvetica, sans-serif;
    }
}

@media (min-width: 72em) {
	.navmenu.academic nav li a {
	    font: 400 1rem 'Luckiest Guy', cursive; 
    }
	.navmenu.academic nav small {
	    font: 100 0.7rem Helvetica, sans-serif;
    }
}

@media (min-width: 80em) {
	.navmenu.academic nav li a {
	    margin: 6px 2px;
	    font: 400 1.25rem 'Luckiest Guy', cursive;
	}
	.navmenu.academic nav small {
	    font: 100 0.8rem Helvetica, sans-serif;
    }
}

Thus we now have a functioning 3-column in page navigation menu for Hyde, and the Software page has a 2-column menu. Nonetheless, these menu solutions need a great deal of tailoring depending on the contents and the environment they are deployed into, so, sadly, I don’t think this will ever be a simple cut and paste solution for other Hyde bases projects.

Unofficial dataonlygreater.com Launch Party

I am pleased to announce the unofficial launch of www.dataonlygreater.com. Note, it is the unofficial launch in case we can have a better party with an official opening. Here is a nice picture of Augusta and I enjoying the festivities.

Party!

So what are we celebrating? Well dataonlygreater is the new conduit for me, Mathew Topper, (find out more about me here) to express my most geeky thoughts (both personal and professional) and share some of the stuff I have been working on, in some ways for the greater good, i.e. open source code.

Currently, the content here is mostly a collection of other work that was still available on the web (mathematicaltopper.wordpress.com, marineresearcher.wordpress.com) or are beyond my control or closed (www.wiki.ed.ac.uk/display/iesscicomp, www.see.ed.ac.uk/~mtopper). The wordpress blogs I will be shutting down as repeated content is bad and the inability to access the other stuff was one of my primary reasons for doing this anyway.

I should say that none of this would have been possible without the amazing piece of software that is Jekyll. Its a great system that I thoroughly recommend you try. I must also thank @mdo for developing Hyde and Joshua Lande for showing me the way. This template is the backbone of the site you see before you. There are also many little concepts and styles that I have pinched from places across the web, so thanks for sharing!

Well, that’s it. Hopefully I will be adding more content on a regular basis and improving what is already here. And, if you’re here looking for the University of Edinburgh Thesis template, don’t worry the page you need is here. Thanks for popping by!

Better zero crossing estimation for fifthwave

Had some difficulties getting decent zero crossing approximations for fifthwave. The main issue is that the data generated from the Starccm+ plots is quite messy in that it is rather zig-zaggy having some points very close to others, but not coincident or even the direction you might expect.

This has caused a number of problems with the code in the past (particularly when estimating wavelength and celerity which relies on good estimation of the zero crossings). The original code had a basic linear interpolation routine checking for a switch of sign and them some error checking after that to make sure it wasn’t an inflection. Unfortunately the messiness of the data made this process extremely unreliable.

Moving onto examining all the waves in the numerical wave tank (NWT) rather than just a region of it required much better estimation of the zero crossings in order to strongly identify which wave was which after a time step and thus, monitor its progress. I needed to smooth the data before it could be really useful and then best solution to this would seem to be splines.

Spline fitting is a pretty heavy bit of mathematics, but I am lucky that the authors of Scipy (the scientific Python library) created an interface to FITPACK (a FORTRAN curve fitting library) called scipy.interpolate. Thus generating splines was not too difficult, it’s just deciding what to do with them. This takes me on a slight tangent where I must express the discomfort caused by using something you don’t understand and the risks associated with that. I have a mathematics degree, but not enough time to learn splines again so I just merrily let the smoothing routine do it’s business and harvested the neat roots() method which gives the roots of the spline (or the zero crossings. Only until the results continued to be a bit rubbish did I actually investigate what was going on and this is what I found.

Spline1

Basically the default spline is absolutely nowhere near the wave form. The smoothing parameter ‘s’ was set way to high (in fact, if it’s not specified its the length of the data i.e O(1000)). Ideally the smoothing in this first case should be O(0.01) which generates a results like this:

Spline2

Close up though this still isn’t perfect and it may be that it won’t calculate this level of smoothing which means that I want to reduce the amount of data that the spline is fitted to, idealy to go from peak to trough to peak. To get a good estimate of the locations of the peaks and troughs, I create another graph of the 1st derivative of the above spline and fit another spline (with even lower s this time) and find it’s roots. This gives me the turning points of the original data. I do need to be careful here, however, as I want to get peak trough, so if there is another peak in there, I skip it till I find a trough. Finally I trim the data to a region between a peak and trough and fit a new spline (default smoothing is fine now), and voila, a good approximation to the zero crossing can be found. Here’s one I made earlier.

Spline3

Finally, I’ll just put a quick summery of the code for getting these plots, etc, so that I can do it again if it all goes a bit airy.

# Import the fifthwave module
import fifthwave as fw
from numpy import linspace

# Set up the wave form data from a csv file
test_data = fw.TwoD_Wave_Form()
test_data.import_csv('mycsv.csv')

# Fit the first spline to that data and plot it
test_data.fit_spline(smoothing=0.01)
test_data.spline_plot('first_spline.png')

# Now build another wave form based on the gradient of the first spline
new_x = linspace(test_data.x[0], test_data.x[-1], len(test_data.x))
new_eta = test_data._spline(newx, 1)

work_data = fw.TwoD_Wave_Form(eta_list=new_eta, x_list=new_x)

# Get the spline approximation and the roots.
work_data.fit_spline(smoothing=0.001)
work_data.spline_plot('gradient_spline.png')

inflections = work_data._spline.roots()

# You can now filter the inflections to make sure they run peak to trough Finally for each inflection move the work data and find the root, i.e there may be a crossing between the start of the data and the first inflection
fromindex = 0
toindex = test.closest_x(inflections[0]) + 1

work_data.x = test_data.x[fromindex:toindex]
work_data.eta = test_data.eta[fromindex:toindex]

work_data.fit_spline()
work_data.spline_plot('final_spline.png')

print 'Zero crossing is at ', work_data._spline.roots()[0]

# Note that the current smoothing factor is not easy to recover from the spline, but in fact it is given by
test_data_spline_smoothing_factor = test_data._spline._data[6]