Oct 13, 2014

Devkumar Gandhi, Mission Peak

Update (Nov 5, 2014): Dev Ghandi lost the EBRPD election by a landslide. I'm super happy about this outcome.


A month ago, I wrote a blog post decrying the change of hours at Mission Peak. The media has been interested in this topic as well, with multiple news articles and video pieces appearing on the recent changes. Most of these are short pieces describing the changes and interviewing a few people they found at the trail head.


I've been doing more research. It turns out that the timing of this change in early September this year is likely meaningful. Elections are around the corner on November 4. Mission Peak is run by the East Bay Regional Parks District which is split up into wards. Mission Peak is part of EBRPD's Ward 5 and its director, Ayn Wieskamp, is up for re-election. Ayn has been on the board for 16 years, re-elected 4 consecutive times. Mid-August, a contender for the election, Dev Gandhi, put his name into the ring.

It turns out that Gandhi lives in the neighborhood right next to Mission Peak. From his website:
To preserve our parks for future generations it is incumbent on us to understand the capacity of our parks and balance that with the visitor demand. 
Mission Peak is a perfect example.  When we moved into the neighborhood close to Mission Peak about 8 years ago, we could hear coyotes howling, owls hooting at night time and see different animals like deer, foxes, bobcats etc. But over the years all these animals have kind of disappeared. Because of immense popularity, hikers visit this park from well before 4am in the morning till about 2am at night almost every day of the year. This has taken a tremendous toll on the preserve and has dwindled the wildlife population to near zero. Currently the visitor usage at the Stanford Ave. entrance is excessive to the point that the Park District is unable to keep up with the on-going damage to the trail/habitats. Problems like these and others need to be addressed with urgency. 
We have to control park recreation to balance with what is sustainable to keep native habitats healthy.
Gandhi is quite interested in reducing Mission Peak access. I suspect the recent hours changes are likely an attempt to persuade a few angry resident voters that a new director isn't necessary to accomplish their goals.


Curious if Gandhi actually lives in the impacted parking area, I turned up this document from the city of Fremont. As it turns out, he lives on a plot of land immediately adjacent to Mission Peak Preserve, but a mile back behind a gated community of residents in Vineyard Heights. This community is adjacent to the park, but is immune from the traffic due to a gate blocking any public access to their roads. However, that same document shows that Gandhi bought an empty plot of land on Vineyard Ave, which is the most traffic impacted road from Mission Peak park traffic. This land was then developed into a new home, which I imagine Gandhi moved into as his previous home sold this July, 1 month before he announced he'd run for the East Bay Regional Parks District Seat.

If this description is confusing, here's a map of the area (click for a larger version):

Roads and homes around Mission Peak park entrance
The blue area is the area I see most impacted from overflow parking. During the weekend, I could imagine this is worse and spreads into the side streets. On the weekday evenings on which I visit (the times that the hours have prevented), virtually all of the impact is along Vineyard Ave, the roughly North-South road on the right hand side of this image. Note that there are very few homes along Vineyard Ave. There are 5 homes to the west and one well set back home to the east whose driveway is inside the Vinehill Terrace Community.

The location of Gandhi's new home appears an empty lot on this image, because until recently it had been just that, an empty lot. As a longtime local resident, the traffic issues, which have been present for years, cannot have come to him as a surprise after he moved in just months ago.

I've never met Gandhi or his opponent. I truly imagine he's a nice guy, enjoys the outdoors like myself, and just wants more peace and quiet. Still, it appears a conflict of interest for Gandhi to represent the parks district. While his newly built home has never been on the market, zillow estimates the 5 bed, 5.5 bath house on an acre of land to be worth $3.3M. Homes in this area may already be the most valuable homes in Fremont. How much would the value increase overnight if the street went from a moderately busy overflow parking street to a resident-only permitted parking area? How much more valuable would the home be if east bay park funds were focused on simultaneously improving this one park while making it less accessible to the public?

Sep 16, 2014

Mission Peak - Residents victory over hikers

"Mission Peak Fremont CA" by Kevin Collins from Alameda, California, USA - Photo from Wikipedia
This week marks my 40th trail hike up Mission Peak this year. A planned summer mountaineering trip to climb Mt Rainier got me interested in Mission Peak. It's steep climb and nearby access made it the ideal training hike. As with most training, I needed to exercise regularly, which for me meant weekday evenings. My standard plan was to hop off of work, drive over to Mission Peak, and climb the mountain for 2-3 hours with a rewarding break to watch the sunset at the top. Sure, there's always a gym, but I never could stand the monotony of walking up a stairmaster. Mission Peak, being outdoors with fresh air and beautiful views was a treat as much as good exercise.

There was really only ever one park that met all the necessary criteria of being within a reasonable drive, a good climb, and most importantly - being open late enough for me to go after work. In Mission Peak's case, the park hours are 5AM - 10PM. Peninsula parks all close at sunset. The next closest park, Henry Coe, open 24 hours, is a ~2hr drive in traffic one way.

My weekly climbs up Mission Peak paid off. I got in shape enough to summit Mt Rainier in July. Along the way, a few coworkers started joining in and carpooling with me after work, all of them feeling great about the exercise and fun they were having.

I write all of this saddened after reading a poorly researched article on SFGate this morning describing how East Bay Parks has decided to change the opening hours on this one park in response to complaints from homeowners living nearby the park entrance. The new seasonal hours are posted on the East Bay Park's website and are seasonal rather than the flat 5AM-10PM before:

Sep 29 – Oct 31: 6:30am – 7:30pm
Nov 1 – Feb 1:   6:30am – 6:00pm
Feb 2 – Mar 7:   6:30am – 6:30pm
Mar 8 – Mar 29:  6:30am – 8:00pm
Mar 30 – Aug 30: 6:30am – 9:00pm

Even for the 5 summer months of the year, this park is now open for 2.5hrs less every day. My evening weekday hikes will simply become impossible in 2 weeks.

Most parks and communities are spending a lot of effort trying to get folks outdoors and exercising in their community. East Bay Parks has succeeded in doing just that with Mission Peak but now seems to be doing everything it can to keep people away.

The main issue is that the park entrance has a relatively small parking lot, with only 42 parking spaces, while on the busiest of summer days there can be 500 cars parked, mostly on public side streets. All of the usual issues that come when homeowners in suburbs see increased traffic around their homes are at stake. These issues aren't without any merit. You can view the main arguments in this summary video by the Vintage Grove Neighborhood Watch Group


My thought is that many of the issues pointed out in this video are incredibly rare. I've parked on these streets more than most people and have not once seen a driveway or fire hydrant even partially blocked. Generally people park on streets here as or more respectfully than in other places.

This is not a park where people bring their family and a picnic that they roll out on the nearest picnic tables. There are 2 picnic tables in the park, nobody uses them, and everyone there is there to hike at least part of the way up a very steep mountain trail. Once in the park, there is no way that even a radio at full volume would be even audible from the nearest homes. Flashlights are far away dots. 

Many of these homes are set far back from the roads inside high walled communities in an area code where the average home price is $2 million. Here's one of the views from the nearby sidewalk: Google Streetview. Many of these homes are fairly deeply hidden behind gates. Certainly the ones affected by weekday traffic fall into this category. If the weekend traffic really does spill further out into the community (I've never observed such) as in this video, then some of the further away homes are a little closer to the public roads. However, the weekday night traffic (times affected by the new curfews) spills only onto Vineyard Ave which has a sum total of only 6 homes along it, all moderately set back from the road.

This is the kind of activity we want more of in the Bay Area. People getting out into nature, getting healthy, and having fun. At Mission Peak, people are doing this by the thousands. There are numerous social groups that hike the mountain together. The Wings of Rogallo Hang Glider group flies off the ridge. At night, REI teaches nighttime photography classes. I've also seen folks using the park for amateur astronomy or doing a night hike to simply watch meteor showers. Much of this is about to end.

I worry that a hundred or so wealthy homeowners would like this gem of a park to be a kind of private park for those who live nearby. Since it's public land, paid for by tax dollars, this isn't possible, but there are things being done to make it more difficult for the public to use. Shorter hours are a big step. Other proposals are to require resident permits for any street parking, limiting public parking to the 42 spots inside the park parking lot. There are proposals to charge entrance fees, with passes for locals for reduced rates. You can get a feel of the desire for this to be a quieter more private park even from the video text:
  • "Hiking up the lower trail, I've got lots of company"
  • "The majority of these people are first time hikers on mission peak"
  • "The majority of these hikers are NOT from Fremont or East Bay"
  • "Counting sensors at the trailhead have recorded 6,000+ hikers in a single day!"
  • "Its popularity attracts hikers from all over the Bay Area"
One of the proposals by the East Bay Parks was to build more parking inside the park, away from residents. Proposals included two different options for building parking with 250-300 spots in each. A pdf showing the parking area proposals is posted online. This idea was brought up after the 2012 summer season. The Fremont city council unanimously supported the idea. The local residents opposed it. This suggests that the residents aren't strictly interested in the parking, it's just an easy issue to get public support on. You can read summaries of the public comments here, here, and here. Essentially there is strong support from hikers and users of the park for more parking, and strong negative comments from locals who oppose any type of increased access to the park.

As for concerns about shortcuts and erosion, the trail restoration programs by local schools and biking groups have been working. The erosion of the trail is decreasing while the number of visitors is increasing. Here are some aerial images from Google Earth. The left side shows an image from 2011 and the right side shows an  image from 2014. Click for more detail.

2011
2014
Bottom of the trail, note the clear parallel bootleg trail to the left of the main trail receding.
2011
2014
A little further up, in 2011 there is a clear bootleg trail running up to the bench in the upper right hand corner of the image. In 2014, it's invisible except from the air.

2011
2014
The same trees as seen at the top of the previous image are now at the bottom of this one. As you can see there were tons of trails taking short-cuts up switch-backs. Most of these are gone. There is some new erosion along the rightmost curve in 2014, but it's just feet away from the main trail, mostly it's the trail spreading out more than a new trail forming.

2011
2014
A little higher up. Most of the bootleg trails are gone. There is a new one that started forming on the upper left switchback, but it's also already been repaired, signs posted, and I've seen almost nobody using it any more, it should hopefully be restored over time. Just a reminder that this needs continuous attention.

2011
2014
So that none can say I'm picking and choosing my photos selectively, these images cover the entire trail. This last set shows the peak at the very top where erosion has not been effectively controlled thus far. The official trail is the one to the left which doesn't actually go all the way to the peak. It's less popular than the bootleg trail which the ridgeline with better views. Most hikers aren't actually aware of the official trail as there is no clear signage at this intersection and the official trail doesn't visually appear to be headed up the mountain from what a hiker could see. This can and should be improved with a maintained trail to the top of the peak, probably along the ridgeline where hikers prefer to go. Lastly here's a video showcasing some of the restoration work. It's done by volunteers under EBRP's supervision, groups are often organized by social media (grr @ 'selfie mountain' reporters):



Similarly with trash, there is virtually zero anywhere on the trail when I hike. I regularly see volunteers on my hikes picking up any trash they do find. I do the same many times. As a result of this attention, the park is more pristine than many less busy parks. There is some trash tossed out along the roads / parking, but it also doesn't seem to accumulate. I've not observed anyone picking it up, but I suspect it's happening as there is always going to be some trash. There is graffiti especially at the top of the peak, but it doesn't build up as volunteers spend hours regularly scrubbing it off the rocks.

Not to mention that none of the above: traffic, parking, trash, noise, curfew violations, erosion, emergency request, etc are reduced by decreasing hours. Those things happen during the day as well, and in far greater volume.

The trail is quite safe, even at night. The large numbers of people hiking it in the evenings ensure there are plenty of people around to help. I've helped carry a large dog down the trail that had collapsed. Folks are quick to offer water to others who look like they could use it. Cell phone coverage is great, and the trail is a fire road 95% of the way to the top, making it possible to access in an emergency. This can't be said for many of the other parks in the area, or even other trails to Mission Peak. The trail that EBRP is directing people to after dark, Ohlone College, has a lengthy portion in a dark, densely forested valley adjacent to a minimally used road in the middle of nowhere. It seems like a fairly dangerous stretch of trail compared to the Stanford Ave trail:

The trail from Ohlone College passes through a more dangerous,
 densely wooded area, behind the ridgeline. It's also less of a workout
and offers poorer vistas along the way.
I've climbed Mission Peak from Ohlone College. It climbs more gradually, behind a ridge with less views until nearing the very top. It's a great alternative, but isn't as nice of a hike. It's less safe - at night, I was the only one on the trail. The parking lot near the trail at Ohlone College is not that large or that empty. Ohlone College has expressed disinterest in encouraging hikers to use their parking lot for hiking up mission peak at the current time.

This isn't just about Mission Peak. Other popular bay area parks should have later opening hours as well, which would serve to take some of the load off of this one. A great example is Rancho San Antonio managed by the Midpeninsula Open Space District.

People from around the bay area love Mossion Peak. I hope that some of these changes are reconsidered in the future.

Aug 17, 2014

Using Nest to push solar savings further

I've received a lot of thanks for my residential solar financials post which goes into quite some detail on how the financials of installing solar work for a PG&E customer.

There is a way to get even more summer power savings out of solar using a programmable thermostat, which I haven't talked about. For me, I really like the nest thermostat, but any thermostat that can operate on a schedule would work.

I talked about this a bit in my prior post, but if you install solar and use power from PG&E you will invariably want to switch rate plans to the E-6 Time of Use plan. The essential idea of this plan is that you pay more for power than before on summer afternoons and you pay less for power the rest of the time. This makes sense for PG&E as hot summer afternoons are when the grid is stressed the most due to homes running non-stop air conditioning. On a hot afternoon, PG&E may actually be losing money on the power being sold (they make the profits up the rest of the year). Solar customers produce more during these times though, so want to be selling their power at these rates and buying at cheaper rates at night.

The base tier rates (as of 2014) are the following:
Summer:
  Peak:         30.661 c/kWh
  Partial Peak: 19.134 c/kWh
  Off Peak:     11.456 c/kWh
Winter (no peak in winter):
  Partial Peak: 13.573 c/kWh
  Off Peak:     11.890 c/kWh

The schedule for these rates (as of 2014) is:
  Summer (May - Oct):
  Peak:         1pm-7pm  M-F
  Partial Peak: 10am-1pm
                7pm-9pm  M-F
                5pm-9pm  Sat-Sun
  Off Peak:     All other times

  Winter (Nov-Apr):
  Partial Peak: 5pm-8pm  M-F
  Off Peak:     All other times

The winter differences aren't that significant, but the difference between peak and off peak in the summer is nearly 3x the price! So, by simply programming one's thermostat's default schedule to account for this, you'll save money. You can see my summer schedule here:

Solar optimized Nest thermostat schedule for time-of-use PG&E rates.


M-F, my wife is often home in the morning, so I leave the thermostat set at 74 until peak time at 1pm, when it turns off (80). If you leave in the morning, it would be ideal to disable it earlier, at 10am. After peak is over at 7pm, I start cooling down the house a bit, and then further at off-peak at 9pm.

Weekends are similarly set up to avoid running during partial peak, except than an hour before the partial peak, I pre-cool the house a bit so that it'll stay cool into the afternoon. I don't know if this pre-cooling actually saves me money or not. It would also definitely depend on the level of insulation in your home, more insulation would make it work better.

Of course, if I'm home and feeling warm, it's super easy to set a more temporary set point that'll override this schedule. I can walk over to the thermostat or change it from my phone if I'm feeling lazy. However, it's rare that I remember to bump the temperature up if I'm heading out for the afternoon and won't be around so this works well as a default.

Aug 2, 2014

Mt Rainier

Last week I spent 6 days climbing Washington's Mt Rainier. This was one of my first introductions to glacier mountaineering, and as such me and my buddies decided to take a longer trip and learn some skills along the way. The most common route up to the summit of Rainier is a two day, 1 night trip. We took longer, but learned a lot of new skills along the way with IMG's glacier skills seminar.


Preparation

Mt Rainier, at 14,410 ft is only 100ft shorter than the tallest peak in the lower 48 (Mt Whitney in CA), but Rainier's trailhead starts over 1,000 ft lower. In addition, Whitney does not require travelling over glaciers to summit, which makes Rainier much more technically challenging. As IMG says, "you will want to arrive in the best shape of your life".

My main training regimen consisted of climbing a small peak in my city's backyard named Mission Peak, a 2200 ft climb over a distance of about 2.5 miles. I climbed this once a week after work, as the park was unusual in that it was open until 10pm. If you are in the bay area, this is a fun trip to do in the evening. It's a popular trail, lots of folks try to catch the sunset from the summit, so it becomes a bit of a party at the top.


In addition to the weekly stroll up Mission Peak, my co-conspirators on Rainier also planned several longer weekend outings which were a mix of adventure and training: backpacking in Trinity Alps and Desolation Wilderness, snowshoeing in the Tahoe mountains, and Ice Climbing in Lee Vining. Jeremy documented many of these trips as well as our Rainier trip over at rainier2014.com.


Day 0, Gear Check

Before spending 6 days on the mountain with IMG, we met up at IMG headquarters to do a gear check. Our guide, Ian, met us there and had us lay out all of our gear and we went through each piece one by one. Due to the amount of gear we did need to take, he had us all pare down our extraneous gear to just the essentials. Everything else was left behind. I added back in a few luxuries that evening: a small inflatable pillow, some down booties, and my 2lb DSLR camera. In addition, we added in a few pounds of group gear such as tents, pots, fuel, and food. Ian then went over some basic skills such as blue bagging (bagging/packing out all waste) as well as answering our questions about the next day and the trip as a whole.

Gear check at IMG headquarters.

Day 1, into the Clouds


A backpack in the the clouds.
Next morning, we were up bright and early to shuttle to a trailhead near Paradise visitor center and begin our climb. It was a pretty short hike to the first camp, only about 2 miles made a little harder by the fact that our packs were quite heavy. The weather was inside clouds and walking on snow, so we wondered how one would navigate in such terrain with few landmarks to go on. When we got to camp, the guides gave us a crash tutorial on setting up 4 season tents in the snow (hint: it involves shoveling out a flat spots and burying anchors in the snow) and we got to work getting settled in. The photo below was taken the next morning when the clouds finally cleared, we had no idea there was a view to be had from camp until day 2!

Camp 1 with Mt Adams in the background

After this we got to work learning how to walk efficiently on steep snow, practicing on the side of a ridge near camp. We had a bit of a scare when Matt post holed through a thin ice layer with one foot, but nobody was hurt. Next, we learned how to self arrest with our mountaineering axes. This is an essential skill - imagine you fall and are sliding down steep slick ice, how do you maneuver yourself to catch your axe on the snow and arrest your slide without having the axe rip out of your hand or rip your face open. We practiced arresting from all possible falls: head first, feet first, face down, face up. This was a ton of fun as it's basically a lot of sliding downhill in the snow. I wish I had some video but the clouds were too dense and I didn't have enough time.

Day 2, onto the Glacier

The next morning, we took down camp and moved up off the snowfield and onto the Paradise Glacier. We had nice blue skies the whole day, which made for some fantastic views both along the hike and at camp.
Panoramic from just above Camp 2. Click for a larger view.
When we got onto the Paradise Glacier, it was time to learn how to work as a rope team. Crevasses are large vertical holes in glaciers that can drop tens or hundreds of ft, which is not something you want to fall in. The problem is that the tops of the crevasses can get covered in thin layers ice and snow so that you can't easily see the crevasses, but you can still break through the layer ice below your feet. To mitigate this risk, we travel on glaciers with each person spaced out 40 or so ft from the person in front of them, but attached via a rope and harness. If one person falls, the others on the team arrest on the snow and then rescue the fallen team member. This particular training built on what we learned on day 1. We practiced this today on the way to camp - tying into a rope, maintaining good distance and communication with the other rope team members.
Take a close look at the ice cave formed by the Paradise Glacier, behind and above the camp.
Distances are deceiving, that was farther away and much larger than it looks in this photo. I think you could have driven a semi through that cave.
This time the area for the camp was a bit steeper and required a lot more digging out of a flat area for tents. We also were going to stay at this camp for two days, so we spent a little more effort making it comfortable, cutting out some steps in our terraces as well as cavities for gear and so forth. That evening we were treated to a lesson about glacier geology. One of our guides had done their master's work on the subject and gave us a little introduction to the basics, while standing on a glacier!

Day 3, 'Rest' day

Today we weren't planning to move to a new camp. This was nice timing as we awoke to unexpected rain at about 4am. We did not get a break from lousy weather until after dinner. Warming up was to one of the best breakfasts of the trip, hot bacon and cheese bagel sandwiches.

Despite the weather, we had stuff to learn! Most of today was spent doing technical work on knots and ropes. Much of this could be done inside the group cook tent with a little storm protection, but whenever the rain abated a bit, we'd run outside and do some more practice there as the tent was a tad crowded.

The final goal for today was to be able to go from an arrest position on a rope team with a member in a crevasse to building an anchor in the snow, transferring the load to the anchor and then building one of various pulley systems to safely pull the victim out of the crevasse. At the end of the day, we got into pairs and practiced exactly this. Unfortunately due to poor weather, we didn't actually get ourselves into a crevasse, but we simulated it on some steep terrain. 

In addition, today we went over some advanced navigation techniques with a map, compass and altimeter. We discussed in some detail how you would navigate in whiteout conditions where angles to distant landmarks were not available.

Finally, after dinner, the clouds parted for a little while giving us some fantastic views of the valleys below with clouds floating through. I captured this series of images which ended up being some of my favorites of the whole trip.

Day 4, Moisture Control

Today, the plan was to take down camp and move up the mountain to Muir Camp. The weather set us back again this morning. We awoke to thunder and lightning. At one point the count between the flash and bang was only a second or two, so it was largely over top of our heads. Rather than get an early start, shelter in place was the plan. Plastic foam pads and staying low to the ground was the safest bet. Walking across a flat snowfield swinging steel ice axes was not. Even if not for the lightning, we small marble sized hail was coming down on our tents.

After the worst of the storm stopped, we decided to get moving. The weather was likely to stay all day, so there was no sense in waiting. The rain was still coming down sideways, but we broke down camp and hiked up to Muir in our storm shell layers ("battle armor"). Unfortunately even gore-tex doesn't 'breathe' or evaporate moisture if it's soaked on the outside. Thus, any sweating we did on the way up just stayed in our clothing and soaked it out too.
The Gombu hut and toilets at Camp Muir

Muir Camp delimits, at least psychologically, the point between lower and upper mountain. Above Muir, we'd be travelling exclusively on rope teams and not for training. For most teams, Muir Camp is the end of day one and the camp from where makes a summit attempt. Muir is also quite lavish - there are a few small structures with bunk beds, an evaporating toilet, even a place to discard used blue bags. We all shared some bunks inside the Gambu hut, named after Nawang Gombu, a nepalese mountaineer who guided on Rainier until a few years ago.

Our focus that afternoon was on getting clothing dry. We ran rope lines throughout the Gombu hut and hung up the most critical clothing. Very little dried completely, but it was no longer dripping wet when we put it on the next morning. 
Bunks inside the Gombu hut, approx -160°G (20°F)
That evening our guides made us some absolutely fantastic burritos for dinner. Apparently pan frying a burrito in olive oil is crazy delicious. Aside: Olive oil is also a super backpacking food. In addition to simply being healthy, it weighs in at a whopping 230 calories an ounce (candy bars are only 100-150 calories/oz). It's stable at a variety of temperatures. It can be added to almost any food and that food magically tastes better. You can use it to loosen jammed up zippers or other gear. It even has useful properties when applied to blisters or sunburns. As a high-fat food, your body must spend a little energy to break it down, which helps you stay warm, so it's great before sleeping.

That evening we spent some time going over rappelling setups and self-climbing rigs. I feel guilty, but I wasn't fully engaged with this lesson. I was cold, wet, and fairly tired. We also learned a bit about altitude related illnesses, but this was fairly familiar stuff to me as I had some first hand experiences on Kilimanjaro.


Day 5, Ingraham Flats

The clouds were still rolling around the next morning, but the rain had dropped down to lower elevations. Climbers coming up from below were soaked, but we were seeing more and more sunlight as the day progressed. We were in pretty good spirits. Today's plan was a short walk up to our final campsite at Ingraham flats. We had plenty of time, so we did a little extra practice of some of our rope and crampon skills.



Early in the afternoon we headed up to the Ingraham Flats. The Ingraham Flats is a campsite on top of the Ingraham glacier. It has an amazing view, one of our guides put it in his top 5 camps worldwide. I can easily see why. Look at the photo above for the camp tents. You can see them on the glacier near the upper left hand side (yellow/orange pixels). The area is apparently a flat part of the geology underlying the glacier and is not prone to crevasses opening up.

Surprisingly, we didn't have to carry tents up to Ingraham Flats, we left those behind at Muir. The tents at Ingraham were buried intentionally under several feet of snow. We dug them out of the snow and set up camp for the last time. The guides have an agreement with the rangers that they can leave tents out at Ingraham for the season as long as they are only set up and visible when they are actually occupied. Another team was coming in the day after us, so we didn't have to tear down the tents.

The rest of the day was short and restful. As soon as camp was set up, we laid down on our sleeping bags. We got up for an early dinner and went to back to bed with several hours of daylight remaining.


Day 6, Summit Bid

The mountain had seen 2 full days of full on storm weather, including hail. Nobody had been on the mountain above camp Muir since our Day 2. Big changes in weather mean big problems. I think most of us expected that the summit would be unattainable due to weather conditions, but we were going to climb as high as we could until it was no longer safe to go further.

Summit day started with a early start around 12:30am. For several hours we were climbing with only our headlamps, but still in a rope team and full climbing gear. At several points our guides continued to be surprised that the rain had made it as high as it did as well as surprise that we were still making progress. There was no visible trail ahead of us. At a few points, we'd have to stop and the guides would go ahead with shovels and cut a small ledge for safety.

I began to really struggle with breathing the last 1,500 ft of elevation or so. The air was thin, I was getting tired and having trouble keeping up with the rope team. Eventually, with some significant help from the guides and team, we made it to the summit of Rainier. We were the first team to summit in 4 days, followed only a few minutes later by several other teams who had gained on us due to the trail we had been cutting.

Photo of our crew on the mountain, I'm on the left in the orange helmet.

We didn't stay at summit for too long as the plan was to descend the entire mountain by mid-afternoon. We downclimbed and glissaded our way all the way back to the parking lot by about 5 in the afternoon. When all was said and done, we had been going for almost 14 hours with only short breaks. I was sore, exhausted, blistered, and all smiles. We said our goodbyes to each other at IMG headquarters, and again over beers.

Jeremy signing the 2014 summit board back at IMG headquarters.

Jun 26, 2014

Temperature Scales

While recently travelling in Europe, I repeatedly needed to convert between published temperatures in Celsius and familiar numbers in Fahrenheit. It got me thinking a bit about temperature scales.

With distance, the multipliers between units at different scale makes a strong argument for metric units. Temperature doesn't have this problem as there is only one unit on each scale (degrees). There is no argument to be made for preferring one scale over another except based on which memorable numbers correspond to real-world values.

Most everyone knows that Celsius is designed around 0° and 100° lining up to water freezing and boiling points respectively. However this definition isn't sufficient for lab purposes. Water freezes and boils at different temperatures depending on pressure and impurities. The technical definition is at one standard atmosphere of Vienna Standard Mean Ocean Water.

Far fewer people know that 0° and 100° in Fahrenheit also correspond to specific real-world values. 0°F corresponds to a temperature when a brine is made of equal parts ice, water, and ammonium chloride. Such a brine, interestingly, is a frigorific mixture, meaning that it stabilizes to a specific temperature regardless of the temperature that each component started at. Thus, it makes for a really nice laboratory-stable definition of a temperature. Similarly, 100°F was initially set at "blood heat" temperature, or the human body temperature. While not super precise, it was a fairly stable value. As good as anything in the early 1700s.

Today, we can produce very specific temperatures in very controlled environments. We hardly need to use water, ammonium chloride, or blood as the master keys to our temperature scales. How could we improve temperature scales if we were to reinvent them today?

I present one possible suggestion. Most people primarily use temperature for measuring ambient air temperature for purposes of assessing comfort level. Why not build a temperature scale around the notion of comfortable air temperature?

0° in this scale then can be centered at a very comfortable room temperature. Something around the area of 70°F / 20°C.

-100° and +100° could then be at the limits of human comfort ranges. Something around the area of 40°F/5°C and 100°F/35°C respectively.

Now, the phrase "tomorrow it will be twice as cold" can be represented reasonably in mathematical terms - simply double the current temperature and you'll know tomorrow's temperature, a feat that didn't always work so well with older temperature scales.

We need a new symbol for this new scale, so as not to confuse anyone (more than necessary). I propose °G, pronounced "degrees Gregable".

Jun 25, 2014

One Year of Solar - And a tale of how PG&E ends up the big winner

Last year around this time, I posted about the theoretical financials installing solar panels on my house as well as some real data from the first month of the system live. It's been a year now, and I have solid data about what our system looks like for an entire year.

Net Grid Usage


Here's a scan from my latest PG&E true-up bill showing the last 12 months of power usage / charges. As you can see, in the winter months I was using more power than I was generating and was paying $10/month or so for the power that my panels couldn't provide. However, in the middle of the summer I was generating enough power to end up with a $30-$40 credit each month. After one year, I had accumulated $100 of power credits*! This is much better than my estimates of the panels covering about 85% of my power costs during the year.

Generation

While PG&E can only tell me net power, SunPower gives me data on how much power I actually produced.



Our estimate was around 4,830 kWh / yr, but we actually produced 5,806 kWh (20.2% higher). 

Why did we produce more? My guess would be the dry year we've had in CA, leading to a statewide drought. Fewer rainclouds equal more sunlight.

PG&E Credit (*)

So, did PG&E cut us a check for $104.74? Unfortunately No.

The accounting you see in the first image pays me retail rates for the power I generate. My generated power gets sold to my neighbor by PG&E at say 12c/kWh, and PG&E then pays me 12c/kWh for that power (hand waving as their is tiering involved).

However, this accounting is only used to determine a credit that can be used against charges later in the same year. In order to be paid, PG&E re-does all of the accounting. They start over, charging me retail rate for the power I buy, but paying me wholesale rate (4c/kWh I think) for the power I sell them. Under this setup, I'd end up having to generate 2-4x what I use in order to break even. I'm nowhere close to that, so the "cut Gregable a check" accounting is zeroed out.

On top of this, even though my monthly bill is $0 and PG&E is profiting from the power I put on their grid, PG&E now charges me $5/month minimum for being connected to that grid. Thus, I still paid PG&E about ~$60 last year for electricity rather than PG&E paying me ~$100. I buy natural gas from PG&E too, but the power credits don't get to count against those charges either.

I'm happy with the results of my install, and knew all of this up front, but still feel like this sets up bad economic incentives. This particular setup means that someone installing solar really wins the most if they install less than the amount they will need, since over-generating results in benefiting only the power company. Even if my roof is a better spot for panels than my neighbor's, the incentive is for me to put less panels on my roof and them to put some more on theirs, rather than the more efficient distribution.

Right now, power companies seem to be trying to fight solar by adding minimum monthly charges and getting permission to pay less than retail rates for the power they buy. This is even after the fact that the solar production is often at times when PG&E pays more for power wholesale than they charge retail. I personally think power companies should be able to charge some type of distribution cost to solar users for generated power, but they should continue to buy the power at (discounted) retail rates even to the point of cutting the solar user a check. Allowing the power companies to have both advantages has an effect of subsidizing fossil-fuel power generation at the cost of solar customers.

Feb 18, 2014

Network Aware Sheetfed Scanner


A little over 3 years ago, I posted a question asking about a consumer product available for scanning to a network drive.

These days there are plenty of options, so I went out and bought an brother MFC-7860DW. I hadn't researched this heavily, so don't consider this a review. It's a scanner/printer that can handle wifi (handy where I wanted to put it), print duplex (yay), and can scan via ADF (automatic document feed, aka sheetfed) straight to a pre-configured FTP location. I overlooked one feature, duplex ADF scanning, which I wish I had.

Now that I have a scanner that uploads to a local FTP drive, I wanted more. I wanted to then automatically upload to a Google Drive folder. Google Drive has very good automatic OCR of all text in uploaded scans, is accessible anywhere, and it's much better than an FTP directory in terms of usability. I can even load documents on a cell phone app.

I started a small project that would monitor for new files on the FTP drive and then upload them to Google Drive. I thought this would take an afternoon, but 600 lines of code later and I'm only now feeling done with the project. I did throw in learning go as part of this, which didn't help things.

The project is here if it inspires anyone: https://github.com/Gregable/ScanServer

One of the big issues I didn't think about initially was that scanned files wouldn't be instantly "complete". It would take several seconds between a file being created and finished uploading from the scanner. If I started processing the file too quickly, I'd get a partial upload. If I slept too long, I'd add too much latency to the whole process. I wanted to largely be able to look at the uploaded file seconds after scanning it so I could verify that it looked right before disposing of (shredding) the scanned document, so latency wasn't a great idea.

Another issue was scanning duplex. I thought it should be possible to scan two single-sided documents and have my script merge them. As it turns out, this is possible, though tricky. If you flip a multiple-page document over, the page order is reversed. As a result, you need to interleave pages backwards. Something like:

  1. Front doc, Page 1
  2. Back doc, Page 3
  3. Front doc, Page 2
  4. Back doc, Page 2
  5. Front doc, Page 3
  6. Back doc Page 1
My scanner had the ability using buttons to select different filename prefixes for uploaded docs, things like "laser", "receipt", "estimate", I ended up choosing one of the prefixes to indicate duplex docs. I then had to think about error cases. What if a user accidentally scans only the front half as duplex and marks the back half as single-sided. Or vice-versa. In these cases, I wanted to upload the document as two single-sided documents. What if I saw two duplex documents come in, but they had different numbers of pages. In this case, I wanted to treat the first one as a single-sided document, but keep the second as potentially the first side of a duplex document that might come next. What if I saw a single duplex document come in and nothing followed? In this case, I wanted to wait 15 minutes to see if I got the other side of the duplex document, and if not give up and treat it as a single-sided document. These cases were fun to work through.

Ultimately, I had fun implementing this with go channels and goroutines. I had one goroutine in a loop monitoring for new ftp documents and managing waiting until they seem to be "finished" uploading before outputting the document to a channel.  I had another goroutine sorting out the duplex / single-sided issues, creating merged documents from duplex uploads, and handling the user error cases above. This goroutine spit out the documents to be uploaded to Drive into another channel. A third goroutine uploaded to drive and spit out to a "final" channel which cleaned up any temporary files created and echoed success messages to the console.

I also moved this little project over to a raspberry pi. As a result, I don't even need a computer running to have this setup going which considering the ~3W power draw of a raspberry pi makes it a no-brainer to leave running continuously.

Jan 12, 2014

Mt Olympia Hike, Part of Mt Diablo State Park

I'm posting a little trip report mostly because I couldn't find too much good information ahead of time. Hopefully this will be useful to someone else.

I found a brief description of this hike in Weekend Sherpa. It's a ~6 mi hike up and down Mount Olympia on the back side of Mt Diablo Park. The climb has ~2,000 ft of elevation. It's not even gains though, so once you really get climbing it averages about a 20% grade with brief blips at or above 30%. The trail is also very narrow at spots making footing a little tricky. At no point did I feel it was dangerous beyond the slight risk of twisting an ankle though. You can see the route and elevation profile on strava: http://www.strava.com/activities/105653802

It was a fun trail. Mostly exposed, there were some great views. The geology is interesting with several outcroppings that lent character to the route. Short twisty trees and burned out areas also add color and interest. Not terribly popular, as I think it's probably pretty difficult to find.


SummitPost has a brief description of the trailhead / parking:

Start from the Marsh Creek Road trailhead (elevation 900 feet, there is no sign that says Mount Diablo State Park but none that says "private property, no trespassing" either). Pass under the gated entrace, and follow a dirt road around a small hill on the right.

The trailhead parking appears to be on the South Side of Marsh Creek Road, but it is poorly marked. I'm not 100% sure this is the correct spot, though I think so. It's more of a dirt pullout with a gate across it. There are a couple of mailboxes and when I was there some trash cans had been set out. The gate has some security cameras and signs. It looks like private property except that one of the gates has a Mount Diablo State Park sign on it, presumably new since the SummitPost writeup. There are no parking signs, but similarly no "no parking" signs either. When I arrived there were 2 other cars, 3 others when I left. Here's what it looks like on Google Streetview:


The maps available online also don't have most the trails marked. Google Maps doesn't have them marked, even Mt Diablo's park brochure doesn't show the trails. The map you really want is the Mt Diablo Interpretive Association topo. I bought mine at the Fremont REI on the way up. Here's a quick view of that section of the map:


You start out walking about a half mile down the unmarked Three Springs Road from the parking lot in the Northeast before coming to Mt Olympia trail markers. The trails are well marked, fortunately. I continued on the road as far as I could and then took the Olympia Trail to East Trail to Mount Olympia. This is a steep but pretty route. On the way back I took the longer route around via Mount Olympia Rd. It's a fire road, not as attractive, but easier on the knees for the descent.

There is also a trail option south from Olympia about a mile to North Peak. I didn't go that route as the peak was shrouded in clouds and I was getting chilly at the top of Olympia as it was. I may return some time and take this option though.

Oct 6, 2013

Majority Voting Algorithm - Find the majority element in a list of values

I haven't done an algorithms post in awhile, so the usual disclaimer first: If you don't find programming algorithms interesting, stop reading. This post is not for you.

On the other hand, if you do find algorithms interesting, in addition to this post, you might also want to read my other posts with the algorithms tag.

Problem Statement

Imagine that you have a non-sorted list of values. You want to know if there is a value that is present in the list for more than half of the elements in that list. If so what is that value? If not, you need to know that there is no majority element. You want to accomplish this as efficiently as possible.

One common reason for this problem could be fault-tolerant computing. You perform multiple redundant computations and then verify that a majority of the results agree.

Simple Solution

Sort the list, if there is a majority value it must now be the middle value. To confirm it's the majority, run another pass through the list and count it's frequency.

The simple solution is O(n lg n) due to the sort though. We can do better!

Boyer-Moore Algorithm

The Boyer-Moore algorithm is presented in this paper: Boyer-Moore Majority Vote Algorithm. The algorithm uses O(1) extra space and O(N) time. It requires exactly 2 passes over the input list. It's also quite simple to implement, though a little trickier to understand how it works.

In the first pass, we generate a single candidate value which is the majority value if there is a majority. The second pass simply counts the frequency of that value to confirm. The first pass is the interesting part.

In the first pass, we need 2 values: 
  1. A candidate value, initially set to any value
  2. A count, initially set to zero.
For each element in our input list, we first examine the count value. If the count is equal to 0, we set the candidate to the value at the current element. Next, first compare the element's value to the current candidate value. If they are the same, we increment count by 1. If they are different, we decrement count by 1.

In python:

candidate = 0
count = 0
for value in input:
  if count == 0:
    candidate = value
  if candidate == value:
    count +=1
  else:
    count -= 1

At the end of all of the inputs, the candidate will be the majority value if a majority value exists. A second O(N) pass can verify that the candidate is the majority element (an exercise left for the reader).

Explanation

To see how this works, we only need to consider cases that contain a majority value. If the list does not contain a majority value, the second pass will trivially reject the candidate.

First, consider a list where the first element is not the majority value, for example this list with majority value 0:

[5, 5, 0, 0, 0, 5, 0, 0, 5]

When processing the first element, we assign the value of 5 to candidate and 1 to count. Since 5 is not the majority value, at some point in the list our algorithm must find another value to pair with every 5 we've seen so far, thus count will drop to zero at some point before the last element in the list. In the above example, this occurs at the 4th' element:

List Values:
[5, 5, 0, 0, ...

Count value:
[1, 2, 1, 0, ...

At the point that count returns to zero, we have consumed exactly the same number of 5's as other elements. If all of the other elements were the majority element as in this case, we've consumed 2 majority elements and 2 non-majority elements. This is the largest number of majority elements we could have consumed, but even still the majority element must still be a majority of the remainder of the input list (in our example, the remainder is ... 0, 5, 0, 0, 5]). If some of the other elements were not majority elements (for example, if the value was 4 instead), this would be even more true.

We can see similarly that if the first element was a majority element and count at some point drops to zero, then we can also see that the majority element is still the majority of the remainder of the input list since again we have consumed an equal number of majority and non-majority elements.

This in turn demonstrates that the range of elements from the time candidate is first assigned to when count drops to zero can be discarded from the input without affecting the final result of the first pass of the algorithm. We can repeat this over and over again discarding ranges that prefix our input until we find a range that is a suffix of our input where count never drops to zero.

Given an input list suffix where count never drops to zero, we must have more values that equal the first element than values that do not. Hence, the first element (candidate) must be the majority of that list and is the only possible candidate for the majority of the full input list, though it is still possible there is no majority at all.

Fewer Comparisons

The above algorithm makes 2 passes through our list, and so requires 2N comparisons in the worst case. It requires another N more if you consider the comparisons of count to 0. There is another, more complicated, algorithm that operates using only 3N/2 - 2 comparisons, but requires N additional storage. The paper (Finding a majority among N votes) also proves that 3N/2 - 2 is optimal.

Their approach is to rearrange all of the elements so that no two adjacent elements have the same value and keep track of the leftovers in a "bucket". 

In the first pass, you start with an empty rearranged list and an empty "bucket". You take elements from your input and compare with the last element on the rearranged list. If they are equal you place the element in the "bucket". If they are not equal, you add the element to the end of the list and then move one element from the bucket to the end of the list as well. The last value on your list at the end of this phase is your majority candidate.

In the second pass, you repeatedly compare the candidate to the last value on the list. If they are the same, you discard two values from the end of the list. If they are different, you discard the last value from the end of the list and a value from the bucket. In this way you always pass over two values with one comparison. If the bucket ever empties, you are done and have no majority element. If you remove all elements from the rearranged list without emptying the bucket your candidate is the majority element.

Given the extra complexity and storage, I doubt this algorithm would have better real performance than Boyer-Moore in all but some contrived cases where equality comparison is especially expensive.

Distributed Boyer-Moore

Of course, Gregable readers probably know that I like to see if these things can be solved in parallel on multiple processors. It turns out that someone has done all of the fun mathematical proof to show how to solve this in parallel: Finding the Majority Element in Parallel.

Their solution boils down to an observation (with proof) that the first phase of Boyer-Moore can be solved by combining the results for sub-sequences of the original input as long as both the candidate and count values are preserved. So for instance, if you consider the following array:

[1, 1, 1, 2, 1, 2, 1, 2, 2]  (Majority = 1)

If you were to run Boyer-Moore's first pass on this, you'd end up with:
candidate = 1
count = 1

If you were to split the array up into two parts and run Boyer-Moore on each of them, you'd get something like:

split 1:
[1, 1, 1, 2, 1]
candidate = 1
count = 3

split 2:
[2, 1, 2, 2]
candidate = 2
count = 2

You can then basically run Boyer-Moore over the resulting candidate, count pairs the same as you would if it were a list containing only the value candidate repeated count times. So for instance, Part 1's result could be considered the same as [1, 1, 1] and Part 2's as [2, 2]. However knowing that these are the same value repeated means you can generate the result for each part in constant time using something like the following python:

candidate = 0
count = 0
for candidate_i, count_i in parallel_output:
  if candidate_i = candidate
    count += count_i
  else if count_i > count:
    count = count_i - count
    candidate = candidate_i
  else
    count = count - count_i

This algorithm can be run multiple times as well to combine parallel outputs in a tree-like fashion if necessary for additional performance.

As a final step, a distributed count needs to be performed to verify the final candidate.


Birds of a Feather

If you are one of the handful of people interested in voting algorithms and advanced software algorithms like this, you are the type of person I'd like to see working with me at Google.  If you send me your resume (ggrothau@gmail.com), I can make sure it gets in front of the right recruiters and watch to make sure that it doesn't get lost in the pile that we get every day.

Jul 7, 2013

Solar, with some live data

As a follow up to my previous post, Residential Solar Financials, we've now had our solar set up long enough now to get some meaningful data from PG&E:

The panels were installed in late May, but PG&E didn't come out and set up net metering until early July. Until PG&E came out, any extra power being generated was being put back on the grid as a freebie.



Here's the day to day net for June from PG&E. The end of the month was pretty hot and the A/C was getting some real use.

Here's an example daily snapshot. Each bar represents power consumption for 15 minutes. A/C got some use in the evening to cool down the house. You can see a nice curve from the solar output with some chunks missing where we had a load running.
Scan from our electricity bill for June. The different bars represent the 3 different time-of-day rates. We don't generate much power in the off-peak rate as most of this is night-time. We banked $32 of energy credits for the winter! Last year we had to pay about $100 for June, so this is a big difference.
In total so far, we're averaging around 20.6 kWh/day of generation, which is actually a little bit higher than predicted.