# Running CARNOT models under OSX

CARNOT (Conventional And Renewable eNergy systems Optimization Toolbox) is a set of MATLAB & Simulink models for simulating buildings and building systems, e.g. boilers, heat distributors etc. It’s been developed by a collaboration involving several companies and universities and is generally well-regarded. It’s one of several MATLAB toolboxes dedicated to the problem of simulating building physics; other toolboxes with a similar goal include the International Building Physics Toolbox and SIMBAD.

CARNOT is in the process of being moved to a new hosting provider. In the meantime, I’ve recently obtained a copy of this toolbox and here is my experience in getting it to run under OSX.

CARNOT is distributed as a zip file, carnot_60_2013b_public_22oct2015.zip. I decompress it and find what looks like a Simulink top-level model called carnot.slx, and several sub-folders. Very encouragingly, I see there’s an installation guide:

I move the decompressed folder to the folder where I keep all my in-progress projects, and create a symbolic link to it named more simply carnot.

The installation guide is very well written, and the main steps consist in:

1. Decompressing the toolbox;
2. Running the init_carnot.m script, that will setup all the paths correctly;
3. Compiling all the MEX file with the provided script.

When I ran init_carnot.m for the first time on my Mac, it didn’t work and the error message made it very clear that most file paths have been written with the assumption that the toolbox was going to be used on Windows. At this point, I could have done either of two things:

1. Fix the issues myself as quickly as possibly and get on with the work;
2. Fix the issues myself carefully, making sure that my fixes could then be sent back to the maintainer of the package.

Being currently on a business trip, I felt like I had the leisure to go for option 2. Seeing that this toolbox was going to need some fixing, I made a git repo out of it and added all its files. (I didn’t know at this point which, if any, files were generated. I figured that this was something I could worry about later and remove those files from the repo.)

I fixed the paths problem, which mostly lay in path_carnot.m, called by init_carnot.m. I created a patch from it and sent it to one of the maintainers. The paths were now correctly setup.

Next I ran mex -setup and this ran fine, MATLAB picked up my XCode installation with the Clang compiler. So the next step in the installation guide was to run MakeMEX.m from the version_manager directory. That ran fine for several .c files until it tried to compile dir2_mex.c. When I opened that file in the editor I saw that it depended on the Windows API. Here I had two options:

1. Try to understand what this file was doing and try to rewrite it without using the Windows API;
2. Skip the compilation of this file and hope that the rest of the toolbox would run fine without it.

The problem with option 1 was that I didn’t know at this point whether there were going to be other files with the same problem. I certainly didn’t want to enter that kind of endless loop of fixing file after file that depended on the Windows API. Since the build process had stoppped on encountering the first error, I had no way of knowing if there was going to be many other problems.

So that’s why felt more appropriate to find where in the call mex was being called, and wrap that call in a try/catch block, yielding a warning if any file failed to be compiled. Re-running MakeMEX now compiled all the files correctly except the single dir2_mex.c, which I hoped would not be needed to run any of the simulations I was planning.

Once this was done, I could finally type carnot at the command line and the toolbox would open:

I was immediately drawn to the box that says double click to open examples and that yielded another set of errors, again related to file paths. After fixing those I could open an example model, the example_House_SFH45, click run, and saw the simulation running. I was all set and done.

A couple of days after writing the first draft of this article, I learned from one of the main developers that they plan to setup a proper SVN repository for the code, and that the whole toolbox was going to released under a BSD licence instead of the current LGPL. Until this is done, I’ve pushed my fixes to a pubic repository on GitHub, to which I have contributed some extra small fixes. But keep in mind that this is in no way the official repository for CARNOT; that will be announced shortly.

Posted on December 9, 2015 at 10:00 am by David Lindelöf · Permalink · 2 Comments
In: Uncategorized

I would like to call this the best second book on R, except that I wouldn’t know what the first one would be. I learned R from classes and tutorials about 10 years ago, used it on my PhD and four articles, and use it today on a daily basis at work; yet only now, after reading this book, do I feel like I could possibly be called an R programmer rather than just a user.

The book deals with a variety of topics that are seldom discussed in the R tutorials you are likely to find freely available. Some are perhaps unnecessary in a book like this (Ch. 5 Style Guide), some could easily deserve an entire book (Ch. 7 OO field guide), but the chapters on Functions, Environments, the three chapters in Part II (Functional Programming) and the chapter on Non-standard evaluation are easily reasons enough to buy this book.

How many time indeed have you spent hours, frustrated, trying to write a function that would act as a wrapper around, say, lattice plotting functions that use non-standard evaluation? Or try to call subset() from another function, only to see cryptic error messages? Now, for the first time, the solution is not only clear to me; I feel like I could also explain to a colleague why things work the way they do.

R is incredibly powerful and dynamic and will, most of the time, do just what you expect it to do. But if you want to really understand what is going on under the hood, or if you want to write your own packages (whether for self-, internal-, or widespread use), you owe it to yourself to read this book.

In: Book reviews, R

# The only problem with daily scrums

Over the past five years, our team has attended more than 120 daily standup meetings, carefully following the “canonical” format and having each team member answer the usual questions:

1. What did you do yesterday?
2. What will you do today?
3. Any impediments?

There seems to be one flaw with this format, however. The flaw is that you cannot say what you will do for the day before having heard if anyone else has an impediment.

For example, if Alice says her bit, announcing what she intends to do for the day and declines to mention any impediments, then when Bob’s turn comes and he mentions that he’s having some trouble and could use some help, then Alice will have to come back to what she has just said and amend her plans for the day.

In Neurobat we’ve implemented a partially debugged hack around this problem by having two standup rounds. During the first round we do the canonical standup meeting, then the ScrumMaster asks if anyone needs a second round. The goal of this second round is two-fold:

1. To let anyone say something he may have forgotten about during the first round.
2. To let anyone amend their plans for the day due to something they may have heard during the first round.

This solution is far from ideal, and sounds annoyingly like a two-pass compiler. But it is, for now, the best approach we have found to deal with what I perceive to be the main drawback to the canonical form of the daily scrum.

In: Uncategorized

# You know you have a great tester on your team when…

… you find a wireless room temperature sensor in your fridge:

In: Uncategorized

# How to fix rotation problems with iPhone pictures

When I take a picture with my vertically-held iPhone, here is what happens when I insert it as-is in this blog:

But the picture shows up correctly when I open it in any OSX application, such as Preview. The issue is that when you take a picture with your iPhone, a meta-data tag gets written to the file telling OSX how to rotate the picture when it is displayed. You can see the tag by using the inspector in Preview:

The offender here is that Orientation tag, which seems to be used only by OSX applications. The best way to fix this is to remove the tag, rotate the picture correctly with Preview, and save it again.

To remove the tag, I recommend using a tool called ExifTool. It’s a neat command-line tool that you can download here. Once downloaded, removing the tag is a simple as this:

$exiftool -Orientation= filename.jpeg  This replace filename.jpeg with the same file but with the tag removed, and save a copy of the original file as filename.jpeg.original. Give it a try, I really recommend it. Posted on November 30, 2015 at 10:00 am by David Lindelöf · Permalink · Leave a comment In: Uncategorized # Reviewer queue During a recent sprint retrospective we raised a problem with the way we assign code reviews. Not the formal, whole-team ones, but the regular ones we solicit for each pull request. The problem was that we tend to select our reviewers based on various subjective criteria, including how well we like the person. I admit I am guilty of this myself. What’s more, during the discussion it became clear that my own help in reviewing code was not asked as often as it used to. At Neurobat we currently have a rule that all pull requests must be reviewed by two other team members (one, if the pull request was paired on). To ensure these reviewers are selected fairly and without subjectivity, we have now introduced a reviewer queue: our names are listed on the main whiteboard and an arrow is drawn, showing who is next in the review queue. When a reviewer is assigned, the arrow moves to the next name. We’ve had this in place for a couple of sprints now and the results have been very satisfying: • people get to review parts of the code they had never seen before • people are “forced” to review code written in unfamiliar languages • the reviews are more likely to be honest and thorough • the review work gets more evenly spread out among the team An added benefit for myself is that by explicitly putting my name among the review queue, I announce my willingness to participate in the reviewing process as much as anyone else. As a result, I’ve been reviewing much more code this last couple of weeks than ever before. If you have a problem in the selection of reviewers in your own team, do consider setting up a review queue and let me know whether that works out for you. Posted on November 27, 2015 at 10:00 am by David Lindelöf · Permalink · Leave a comment In: Uncategorized # How to test for floating point exceptions with CppUTest Some programmers, when confronted with a problem, think “I know, I’ll use floating point arithmetic.” Now they have 1.999999999997 problems. // Tom Scott Floating point arithmetic is notoriously hard to get right. I consider writing a bug-free, optimally performant numeric library to be approximately as hard as writing a compiler. Fortunately, most programmers don’t need to deal with it, unless your work involves anything to do with science or engineering. There’s one subject though where I think you need to be a bit more careful. This is about understanding when and why your program will catch floating point exceptions (FPE). Let’s consider a couple of examples. Consider first this program FPE.java: public class FPE { public static void main(String[] args) { int i = 0; System.out.println("1 / 0 = " + (1 / i)); } }  Compiling it and running it yields: $ javac FPE.java
$java FPE Exception in thread "main" java.lang.ArithmeticException: / by zero at FPE.main(FPE.java:4)  In Java, dividing an integer by zero yields an ArithmeticException. Fair enough. What about floating points? public class FPE2 { public static void main(String[] args) { double i = 0; System.out.println("1 / 0 = " + (1 / i)); } }  Now this yields something different: $ javac FPE2.java
$java FPE2 1 / 0 = Infinity  I’m not sure I like having such a wildly different behavior. But consider now the same programs in C: #include <stdio.h> int main() { int i = 0; printf("1 / 0 = %d\n", 1 / i); }  This is the result (under OSX): $ gcc -o FPE FPE.c
$./FPE Floating point exception: 8  Not exactly the most helpful error message ever, but at least the program crashes. Now the same thing with doubles: #include <stdio.h> int main() { double i = 0.; printf("1 / 0 = %g\n", 1 / i); }  And here’s the result: $ gcc -o FPE2 FPE2.c
$./FPE2 1 / 0 = inf  So Java and C behave similarly: dividing an integer by zero crashes the program, but dividing a double by zero does not. I find it rather unsettling that 1 / 0 should result in a completely different program than 1 / 0.. I realise now that I had assumed all divisions by zero would be caught at runtime and cause the program to fail. This is, however, simply not true. Our code at Neurobat includes a fair amount of numeric algorithms, which are decently covered by our unit tests. However, there remained the small possibility that the code could execute “illegal” floating point operations and silently fail. There is no portable way to force a program to crash when a floating point exception is raised. You need to make sure that floating point exceptions cause a SIGFPE signal to be sent to your program. Only google can help you here, but for OSX here is how you do it. What you can do in a portable way is to test if a floating point exception was raised, and I highly recommend that you check for most floating-point exceptions in your unit tests. I say “most”, because you probably don’t need to test for FE_INEXACT. See the manpage for fenv for details. Here is how we do it in the CppUTest framework. You need to test for exceptions before and after running your unit tests. We use plain assertions because CppUTest doesn’t like that we use its assertions outside of a test run. #include "CppUTest/CommandLineTestRunner.h" #include <cassert> #include <fenv.h> void assert_no_fpe_raised(void) { assert(0 == fetestexcept(FE_INVALID) && "Invalid floating-point exception raised during tests."); assert(0 == fetestexcept(FE_DIVBYZERO) && "Division by zero raised during tests."); assert(0 == fetestexcept(FE_OVERFLOW) && "Overflow raised during tests."); assert(0 == fetestexcept(FE_UNDERFLOW) && "Underflow raised during tests."); #ifdef FE_DENORMALOPERAND assert(0 == fetestexcept(FE_DENORMALOPERAND) && "Denormal operand raised during tests."); #endif assert(0 == fetestexcept(FE_ALL_EXCEPT & ~FE_INEXACT) && "Floating-point exceptions (other than inexact) raised during tests."); } int main(int argc, char** argv) { int result; assert(0 == fetestexcept(FE_ALL_EXCEPT) && "Floating-point exceptions active before tests begin."); result = RUN_ALL_TESTS(argc, argv); assert_no_fpe_raised(); return result; }  So did we ever catch any bug with this? Indeed we did. We use an off-the-shelf optimisation algorithm that minimises an objective function in an$N$-dimensional space. At each iteration, the algorithm needs to compute the middle between two points where the objective function is to be evaluated. It does this by taking the mean of the points’ coordinates, in the naive way:$x’ = \frac{x1 + x2}{2}$. What we found was, that if$x1$or$x2$is large enough, their sum could overflow. What’s worse, the program would not terminate or fail in any visible way, but just return rubbish. Bottom line is that if your program does any kind of floating point computation, consider having your unit test framework check for floating point exceptions. It probably won’t do it by default. Posted on November 25, 2015 at 10:00 am by David Lindelöf · Permalink · Leave a comment In: Uncategorized # Not prioritising architectural needs From Mike Cohn’s User Stories Applied, there was this little paragraph that I think many teams (including my own) tend to forget about: Developer Responsibilities You are responsible for providing information (sometimes including your underlying assumptions and possible alternatives) to the customer in order to help her prioritize the stories. You are responsible for resisting the urge to prioritize infrastructural or architectural needs higher than they should be. Indeed, on a team with technically strong members you will sometimes see proposals for stories such as: Define our services’s API As a developer, I want a clear and stable API so that I can develop the client-side code more effectively. This story has all the virtues of a well-written user story: a clear title, a clear stakeholder, yet left intentionally vague to make sure that people will speak among themselves about it. Yet something is wrong here. The problem is that the story brings value neither to the business nor to the users. It is part of a larger story; it is a task, or a TODO item, masquerading as a user story. It is a (no doubt well-intentioned) attempt at breaking down a larger story into small ones. But it doesn’t work. It doesn’t work because once it is done, you are worse off than when you began. How is this possible? It’s possible because you now own software that is neither finished nor potentially shippable. It is by definition unfinished work, and chances are that the mass of unfinished work will only grow over time. Unfinished work is like inventory: it is waste and it costs money. Instead, it is your responsibility to gently nudge the team towards what’s sometimes known as a Walking Skeleton, i.e. a system that implements a small functionality end-to-end. Try hard to achieve this, and be prepared against any objections the team may have. The benefits are immense, and experience has shown that the resulting system will be better designed and easier to test. Posted on November 23, 2015 at 10:00 am by David Lindelöf · Permalink · Leave a comment In: Uncategorized # Bayesian tanks The frequentist vs bayesian debate has plagued the scientific community for almost a century now, yet most of the arguments I’ve seen seem to involve philosophical considerations instead of hard data. Instead of letting the sun explode, I propose a simpler experiment to assess the performance of each approach. The problem reads as follows (taken from Jaynes’s Probability Theory): You are traveling on a night train; on awakening from sleep, you notice that the train is stopped at some unknown town, and all you can see is a taxicab with the number 27 on it. What is then your guess as to the number N of taxicabs in the town, which would in turn give a clue as to the size of the town? In different setting, this problem is also known as the German tank problem, where again the goal is to estimate the total size of a population from the serial number observed on a small sample of that population. The frequentist and bayesian approaches yield completely different estimates for the number N. To see which approach gives the most satisfactory estimates, let’s generate a large number of such problems and see the error distribution that arise from either approach. n.runs <- 10000 N.max <- 1000 N <- sample.int(n = N.max, size = n.runs, replace = TRUE) m <- sapply(N, sample, size = 1)  We run this experiment n.runs times. Each time we select a random population size N uniformly drawn between 1 and N.max. We draw a random number m between 1 and N, representing the serial number that is observed. The frequentist approach gives the following formula for estimating$N$:$\hat{N} = 2m-1$. Intuitively, the argument runs that the expected value for$m$will be$N/2$.$m$is therefore our best estimate for half of$N$, and hence, our best estimate for$N$will be twice$m$. And I’m not sure where the${}-1$thing comes from. The bayesian approach is more complex and requires one to provide an estimate for the maximum possible number of taxicabs. Let’s therefore assume that we know that the total number of cabs will not be larger than 1000. (The frequentist approach cannot use this information, but to make a fair comparison we will cap the frequentist estimate at 1000 if it is larger.) Then the bayesian estimate is given by$\hat{N} = (N_\textrm{max} +1 – m) / \log(N_\textrm{max} / (m – 1))$. Putting it all together, we create a data frame with the errors found for both approaches: frequentist <- pmin(m * 2 - 1, N.max.bayes) - N bayesian <- (N.max.bayes + 1 - m) / log(N.max.bayes / (m - 1)) - N errors <- rbind(data.frame(approach = "FREQ", errors = frequentist), data.frame(approach = "BAYES", errors = bayesian))  The mean square error for each approach is then given by: > by(errors$errors^2, errors$approach, mean) errors$approach: FREQ
[1] 73436.81
-------------------------------------------------------------------------------
errors$approach: BAYES [1] 44878.61  The bayesian approach yields close to half the square error of the frequentist approach. The errors can also be plotted: library(lattice) histogram(~ errors | approach, errors)  Both error distributions are skewed towards negative values, meaning that both approaches tend to underestimate$N\$. However, the bayesian errors have a tighter distribution around 0 than the frequentist ones.

The bottom line is that, given exactly the same information, the bayesian approach yields estimates whose squared error is about 60% that of the frequentist approach. For this particular problem, there is no question that the bayesian approach is the correct one.

Posted on November 20, 2015 at 10:00 am by David Lindelöf · Permalink · 2 Comments
In: R, Uncategorized

# ISH 2015 — first impressions

ISH, held every two years in Frankfurt, describes itself as “The world’s leading trade fair The Bathroom Experience, Building, Energy, Air-conditioning Technology, Renewable Energies”. At Neurobat we develop systems for improved and more efficient indoor climate control systems, and it was only natural that we attend as visitors.

A small party from our company visited the fair, which was spread out over 12 halls according to topics. Each of these halls would have easily required at least half a day do it proper justice, so it was obviously not possible to visit the entire fair.

My professional interests made me focus on two domains: heating systems and control systems. Here are some key observations, together with some pictures I took:

### Internet connectivity

This was a recurring theme in the heating systems hall. Every single heating system manufacturer seemed to have a solution to connect their system to the “Internet Of Things”.

There appears to be two main benefits from having your system connected to the web: remote control and remote maintenance. Remote control is all about having the possibility (usually through some app) to control your house remotely. Remote maintenance is more aimed at the installer, who will have the possibility to remotely monitor, and proactively intervene on, your system.

It is hard to determine if this is a fad or a long-term trend, but I am very excited by the latter possibility.