The Hot TOTTI: Tower of Total Thermal Integration

[jimmason]

Here's some new pictures and drawings explaining how the various heat exchange systems we've been working on for the GEK, combine together for a full thermal integration of the gasifier - engine system. Cut files and instructions for making all this are coming soon. What is below are the explanatory visuals for how we make and use these in house.

Here's the gist of what we're trying to achieve with these elaborations. The concepts and goals are old. What is new here is a method to realize the goals with tolerable economics and modest logistical complication (thus making it deployable to real users).

------------------------------------------------------------------------------------------




Look Ma! No Radiator!

The waste heat in output syngas and IC engine exhaust has tremendous potential for augmenting the various "thermally challenged" processes in a gasifier. By well recycling and reusing these "waste heats", we can remove the majority, if not the totality, of all the "thermal drags" on the combustion zone in the gasifier. The result is higher combustion and cracking temperatures for improved tar conversion, increased tolerance for high moisture fuels, and increased total gasifier efficiency. At the same time, we can eliminate the need for a radiator to dump heat at the end of the system.

The GEK Tower of Total Thermal Integration (TOTTI) demonstrates a powerful new method to achieve this full thermal integration of waste heats in a gasifier and IC engine system, and do so in a compact and easy-to-build form factor. Full thermal integrations are common on large-scale gasification equipment What is new here is a method and aparatus to achieve the same at the small and mid scale. The usual attempt at this solution is to throw the entire kitchen sink at the problem-- building a long train of filters, exchangers and cooler coponents, all tied together with a mess of plumbing and condensate management. And the result is always a complex and expensive system only a government bureaucrat could love (or afford).

ALL Power Labs now demonstrates the same can be achieved through an economical combination of counter-flow vessels, directly mounted to each other, without a large elaboration of redistribution plumbing or auxillary vessels. All waste heat is reused and returned to approprate temp processes. Cool things are made hot and hot things are made cool, in sync and in order-- thus there is no need for the usual radiator/cooler/condensor at the end to hide your "thermal sins".

The GEK Tower of Total Thermal Integration is the culmination of all our air preaheating, heated auger and PyroCoil work of late. The pictures and drawings show how various old and new GEK parts come together for the integration. Here they are by number and function.

1. Heat Exchanger #1, Drying Bucket: Vaporize water out of incoming fuel with outgoing syngas.
2. Heat Exchanger #2, PyroCoil: Pyrolysize incoming fuel and heat resulting charcoal with IC engine exhaust heat.
3. Heat Exchanger #3, Reactor/Gas Cowling: Preheat incoming air with outgoing syngas.
4. (Optional) Heat Exchanger #4, Cyclone with Steam Coil:
Remove majority of particulates before drying exchanger to prevent soot clogging. Raise filter water to steam for reinjection into reactor.

The Drying Bucket is the newest component for the GEK gasifier system. The Drying Bucket replaces the previous longer heated auger unit described here. Unlike a typical heated auger design, the Drying Bucket mounts directly on top of the cyclone, and directs all outgoing gas heat to vaporize water from the incoming fuel. Vaporized water rises up with a convection draft into the monorator hopper, and condenses out on the cool hopper walls. In contast, water vapor liberated in a heated auger does not have anywhere to condense, and thus will still travel into and through the reactor, though with the vaporizing load helpfully removed. Removing the water completely, then reintroducing it dynamically as temps and loads require should create a bit more flexibility.

A big concern when using gasifier output or IC exhaust to dry incoming fuel is to not get the fuel too hot and start torrefaction or pyrolysis in the drying vessel. There is a fairly narrow band where temps are high enough to vaporize water (100C) and not too high where torrefaction and pyrolysis will begin (@200C). Thus the TOTTI system is first tempering the output gas heat with air preheating and cyclone losses (potentially with steam coil), before the output gas enters the Drying Bucket double jacket.

All this of course assumes you want to keep drying separate of pyrolysis. We think this is important so shut down is not complicated by pyrolysis smoke, fuel to load matching is improved, and you can keep pyrolysis tars out of the drying condensate. Continuous run units at constant load don't need to worry about this as much, though mixing of drying and pyrolysis in an auger can create a big sticky mess. The DTU Viking unit, for instance, mixes pyrolysis and drying in the heated auger. This is fine for research and modelling, but non-ideal for small scale start and stop type uses with real world operators. Thus we've gone to a system where the auger stage is drying only, and pyrolysis is supported in a separate gravity fed downward stage. The two are kept as separate as possible.

There are many other subtle yet important details for which waste heats should be returned to where, as well as the orientation of physical components that will best realize the desired thermal relationships and flows. The TOTTI is our best solution and likely final answer for establishing the correct total system thermal relationships, while also attending to the rest of the 3-D thermal-chemical-mechanical-gravimetric puzzle that is gasifier design.

[GasMe Baby]

Hmmm torn. Buy now or wait to see what you come up with next. This is worse than deciding to get a 'puter. :) Great job! Love the improvements!

I'm confused a little about the "no radiator" comment. Exhaust usually goes out a muffler and dumps heat into the atmosphere, right? Radiators are used in a liquid cooled system to remove heat from the cylinder walls & engine in general. How does the utilization of exhaust heat affect the need for a radiator? Is there any use for hot liquid from a liquid cooled engine?

Gotta go look at your price lists again...

[jimmason]

the no radiator relates to the gasifier, not the engine. the point is to not need the radiator/cooler for the output syngas, as the heat is being used elsewhere for useful things.

full disclosure:

i am now happy with this integrated system architecture. i will be stopping here for a good long while. there will be no major changes to the heat exchange vessels or basic gasifier vessels for the forseeable future. all the fundamentals are strong. now we'll work on many details. some new bolt in reactors and reactor details too. all go into the current basic system.

there is no hail mary around the corner that is going to change all this. the current things are mature and good. and all the current things remain interoperable with everything that has come before. the v1 - v3 are near identical in vessel dimensions and flange mounting sites so those with the previous versions can do all the things now offered for the current version.

maybe we're already at OSX. we can build on these fundamentals for a long while. it's not as bad as a computer. there is no moore's law in gasifiers or energy in general. there is no regular doubling that changes everything. that is mason's law. thermodynamics is a brutal task master. unity is approachable, but unmovable. the physical world is difficult that way . . .

jim

When is it likely that this add-on will be available on the price list?

[JayMart]

Coming from a background of academic research and development I believe in full disclosure and a fair and independent review of results and claims. At this point there are a few things that are missing in the current presentation ( ok, I've been reviewing journal articles for the past couple of days ). A solution to a problem has been proposed. A few details of the solution have been provided, but not enough to independent repeat/validate the experiments.

We are also missing the details of the problem statement. There have been fragments describing the problem but not clear statement of what is the percieved problem. The problem as I see it is that a downdraft reactor in its current design generates too much tar to be used as a fuel for an internal combustion engine (ICE). The use of an ICE as the consumer of the generated gas is a condition that has been placed on the requirements for the design that may not apply to everyone that is using the GEK. An alternative application of the GEK may be to use the gas directly for cooking or heating, in which case the production of tar may not be an important contraint to the system design.

The current design modifcation have presumed use of an ICE engine, which I think is a good assumption. As a result, this places other constraints on the system that become important factors in the design such as intake temperature of the generated gas, the power density of the generated gas (% of H2 and CO and possibly CH4 or other short chain gaseous hydrocarbons in the gas stream), the stability of the process, and the "turn-down ratio" of the process (i.e. the percentage of the maximum production rate that can be sustained controllably). The constraint imposed by removal of all tars from the ingestion of the ICE signifcantly limits the possible design options. These options have been (as identified by Jim) either post generation scrubbing (filters) or reduced tar generation through better control of the combustion/reduction processes. There are some similarities here to the design issues that diesel engine manufacturers have had to grapple with in order to meet new emission standards. Many manufactuers were considering putting large bags in the stacks of over-the-road trucks that would have been replaced very frequently.

I fully agree with the direction chosen by Jim and company to attack the tar clean-up issue by reducing the tar generated rather than improve filter designs. Filters can be expensive to clean-up, become a maintenance issue for long-term use, and tend to reduce the performance efficiency of the system. Given this approach, it would be good to see some more background on how tars are produced. What are the processes and conditions that generate tars? I think that some of these things are being quantified now, but it is being done after the solutions have been developed. The results of these investigations should identify the "low-hanging fruit" in the design. I think that a standard test set-up should be published so that many of us users/researchers/developers/tinkerers can try to reproduce the same results to identify potential variability in the designs (i.e. are there significant sources of uncertainty that we are not aware of yet?) and to allow exploration of the huge variety of design and operating parameters that may impact the performance of the system. For example: 1) should we use a constant vacuum to draw air into the system, 2) where should the thermocouples be placed within the system, 3) what common elements should we all have in our hardware (hearth size, reactor dimensions, ...).

It has been presumed by Jim and company that the addition of waste heat from the ICE is a significant improvement to the process. Is there any way to quantify this? Is there any evidence that a significant amount of the heat is being removed from the exhaust gas stream and is being introduced into the fuel side of the equation. What are the expected improvements of this addition? I assume the desire is to make the whole system more robust to a larger variety of fuels. What are the controls to the process that we currently have? A PID loop controller has been identified - what is it controlling? How will this be integrated with the operation of a combustion engine? What is expected start-up procedure for the reactor? How is it determined when it is safe to start dumping the generated gas into the ICE?

I think the answers to many of these questions have been considered by the folks at APL but, so far it seems to be a "watch us and see what we give you" when it should be a little more this is what we are thinking and why - and here is the objective evidence. I think the development process should be a bit more inclusive of those outside of APL. It can become frustrating to see all these claims and changes being made without any real justification of why, what are the problems that are being solved? how effective is the solution?

This has been a bit of a rant, for that I must apologize, but I want to see a process where we are all contributing to the solution those pieces in which we can contribute instead of watching from the sidelines for whatever new things come out of APL, trying to reproduce some of the results with very little background of the changes that are being made and why.

I still applaud APL for their dedication to the development of the open source gasifier and those that outside of APL that are trying expand the understanding and applicaiton of this old technology to be a viable answer for some of todays renewable energy issues.

Jay Martin

[jimmason]

Originally Posted by pgt7787

When is it likely that this add-on will be available on the price list?

it is available now. we're starting a batch of 10 of the drying buckets today in fact. just got cut and rolled.

the TOTTI is the combination of the Drying Bucket and PyroCoil bolted together. you can buy either or both together. they come in both fully welded together and painted, or you weld together and paint forms.

the prices are:

Drying Bucket (with all motors, fuel level sensing and auger doghouse for top of reactor)
welded: $995
unwelded: $595

PyroCoil:
welded: $695
unwelded: $395

the Drying Bucket with short auger is going to replace the long auger with drying bucket. we've not changed the purchase page yet, but that is what will happen.

more info at: http://www.gekgasifier.com/purchase/#GCU

[jimmason]

Originally Posted by JayMart

Coming from a background of academic research and development I believe in full disclosure and a fair and independent review of results and claims. At this point there are a few things that are missing in the current presentation ( ok, I've been reviewing journal articles for the past couple of days ). A solution to a problem has been proposed. A few details of the solution have been provided, but not enough to independent repeat/validate the experiments.

This has been a bit of a rant, for that I must apologize, but I want to see a process where we are all contributing to the solution those pieces in which we can contribute instead of watching from the sidelines for whatever new things come out of APL, trying to reproduce some of the results with very little background of the changes that are being made and why.

Jay Martin

jay, i'm thrilled to hear that you want more open collaboration. this continues to be the goal, and we're constantly trying to do better at it. oddly, i often find myself struggling on the opposite side of your note- namely how to get people to participate in the nitty gritty of all this. it often seems that we've put up such a massive amount of information, design options and process architectures, that it is overwhelming to most. we're trying to figure out how to better layer all this so that it remains accessible and useful for people at different levels of interest. in general, i am told that it is already too much.

also we are very challenged by this still being very new. people are still just really getting units and testbeds set up so we can more meaningfully collaborate over it. hardware is unfortunately much slower than software. we're trying to put up as much helpful info on set up and testing as we can, but we're limited by the usual time and materials issues. we realize these holes and are working to improve them. more importantly, we invite others in to engage, curate and elaborate the parts that are personally of interest to them.

while doing all this, we have to deliver products that are relevant to users as quality products, but also products that support the experimentation that will make the products better. there is tension in your note between "where is the testing that proves things are as claimed", and "why did this arrive so done and we can't develop it in an open iterative discussion here". this is the same tension we feel. we have to deliver good solutions, but also point out where the low hanging fruits of continued work are to make them better. we have to put this out before it is fully tested like typical consumer products, but still known to be better than anything else available so it will be uniquely enjoyed and improved by its users. thus in some sense we are selling our research and development process. we are selling it in a form that is immediately useful to others, enabling them to do things not possible just a year ago, with expert elaborations not previously considered. we are also revealing our r and d process openly to benefit the larger public conversation and understanding.

this is not a VC or govt funded endeavor. we have to make ship if there is going to be anything here tomorrow. it is a bracing reality daily. it stands one up straight and sober every morning. we must ship product known to be useful and mature, but also able to support a rich process for how to make it better. we iterative fast and broadly. ideas become things made and shipped in a matter of weeks. many ideas discussed here and on the other lists have gone from idea to in the mail in under a month in the last year. these are the pleasures and opportunities of desktop manufacturing that we did not have just a few years ago. the manufacturing can now become part of the research process and general conversation. constant change and improvement. halfway between prototyping and rote reproduction. an intimate combination of science, engineering, manufacturing and user hacker culture. i have found this to be a very powerful combination. things get better much faster and more honestly. and this will only improve the more we can figure out how to meaningfully involve you and others like you in the nitty gritty of it. i'm all ears for ideas for how we can do this better. it is a very different type of r and d process than the academic process (from where i come too).

one of the main things we try to do to make this possible is get good test EQ into everyone's hands. this is why every kit comes with free test EQ when we could really just ignore this and most potential buyers would not notice the lack up front. it was a very geek indulgence when we started including these things int he beginning, but i thought it important that everyone could talk in numbers and not "it works" or "it doesn't work", which had been where much of our assessment was previously.

the problem with test EQ is it is expensive. we had to figure out how we could get all the needed basics into people's hands for near free on our end. after lots of work we can now include instruments for temp, pressure, fuel moisture and tar testing with every kit. flow rate is a very minor addition, which we'll also likely add soon. you understand how much all this would cost if bought immaculately from omega. we can now do the whole lot for under $100 in materials costs to us. there is a forest of trees to learn about just with these manual instruments. (and yes, our instructions for how to use them are not good. we need to add lots to those parts of the wiki).

the next major step has been and continues to be getting high end scientific sensing and control EQ into the hands of more serious users. that is the point of the GCU. we couldn't find a hackers level board that did all the temp and pressure things needed for testing and process control, so we had to make it. it will now do things like this. this is the run from last night.
http://gekgasifier.pbworks.com/Instr...ell-Run-080309

don't like this one? there will be another one tomorrow night most likely. what previously only a research lab at a university could do, after great effort and cost of unique set up, now any gasifier enthusiast can do over modest money and a standardized system. we can now generate deep data as we vary all parameters of interest and fuels available.

however, setting up the instruments in the machine that feed the GCU has been a bit more than expected. we're still really just testing the testbed. actually, the test above has most all experiment process issues in reasonable order. bear is arriving at happy with it. not fully. but close.

bear has been highly encouraged to publish more details on how he is setting up all these pokers and measurers and running the sessions. there will be a large elaboration of detail on the process in the wiki soon. we are not trying to keep it secret. it's just been a lot.

in the interim, bear and i get lost in these charts and graphs from the tests near daily. the closer you inspect them, the more they reward. i hope very soon we will be discussing design issues here in the forum over the real data of these tests.

others are highly encouraged to set up parallel test beds on their geks. we're trying to get all the best tools in your hands to do it. we're tried to make it all as cheap as possible. the long standing problems of small scale gasification no longer need to be only speculative or exotic concerns. the tools are now accessible for individual enthusiasts to engage the deep science and engineering. therefore i hope more of you will join us down the deeper reaches of the rabbit hole as we finally solve the gasifier problem.

jim

Originally Posted by jimmason

full disclosure:

i am now happy with this integrated system architecture. i will be stopping here for a good long while. there will be no major changes to the heat exchange vessels or basic gasifier vessels for the forseeable future. all the fundamentals are strong. now we'll work on many details. some new bolt in reactors and reactor details too. all go into the current basic system.

there is no hail mary around the corner that is going to change all this. the current things are mature and good. and all the current things remain interoperable with everything that has come before. the v1 - v3 are near identical in vessel dimensions and flange mounting sites so those with the previous versions can do all the things now offered for the current version.

maybe we're already at OSX. we can build on these fundamentals for a long while. it's not as bad as a computer. there is no moore's law in gasifiers or energy in general. there is no regular doubling that changes everything. that is mason's law. thermodynamics is a brutal task master. unity is approachable, but unmovable. the physical world is difficult that way . . .

jim

Looking at the steady state test runs it would seem that one factor upsetting the system is the grate shaking and ash removal. Is there a possibility of an automated augur for ash removal so that the air flows are not sunstantially varied?

[JayMart]

My previous comments were mostly meant to encourage you and the folks at APL to not let the desire of expediency trump the need for documentation and discussion. Most eveyrone is motivated by developing new things and look at documentation as a necessary evil. New developments, whether a success or failure need to be documented and published so other are aware of them. We need to learn from the experience of those developed of this technology during WWII. They most likely wen through many of the same discovery process we are going through now, came up with solutions, but did not publish them. Those solution are now lost with the technology that was abandoned at that time. We can not afford to make the same mistake.

I will be the first to admit I hate documenting the research I do, but I know that it is necessary. What use is someone that develops a cure for cancer if they never tell anyone else the solution? It may seem that documentation slows down teh process of development, but in the end it will save time by recording the steps taken to generate the observed results. Our memories are finite and fallible - we will all forge the details of what we did. I know I do.

I know that you are trying to be open with the developments and I applaud that. I only wanted to indicate that their are other soldiers in this war that are willing to help and are being somewhat sidelined by the lack of a publishing the current strategy to achieve the vision and goals that are fairly well established for this project.

In terms of delivering a product. I understand the need to deliver a product to help pay the bills for continued developments, but this is still the GEK. The E is for experimental. It may soon be time to have two separate lines of product development - one for GEKs and one for GKs. The GKs may come in different sizes according to the desired application.

Thanks for all you do in gasification

Jay Martin

[bear@apl]

Hi Jay,

Thanks for the input. Trying to stay on top of reporting while also getting to a point where the tests are controlled and meaningful.

Starting to get there with the most recent run:
http://gekgasifier.pbworks.com/Instr...ell-Run-080309

Admittedly a bit of a firehose of graphs and data, but we're starting to get to the point where we can truly address the conditions that minimize tar production, and generally see how the system runs.

I'm open to ideas for better collaboration and feedback on testing. One thought may be to break out a section on the wiki where test results can be reported by topic area (grate agitation, tar vs. temps, temps vs. reactor flow, fuel characteristics, etc). Pull results from separate runs into those areas, discuss methodology improvements, new hypotheses, etc.

Cheers,
Bear

[JulietteKlonk]

Hello,
very interesting,i want to buy one.
Thanks for share.