All Activity

I wonder whether they could reliably locate the old drawings and calcs - might they have slimmed down the sections at the top of the building, perhaps during construction, not expecting that anyone would put on another 19 floors 60 years later. Also, do they ever produce as-built drawings after the fact for big commercial buildings likethat? Lastly, was there any reliable way of verifying the section many years later after the concrete was sprayed on? For all the beams/columns?

Just ask the planner, drop them an email and get it in writing. Disagree as we have no other information.

I think you're right. Had got myself over excited with the SE stuff! Hope all is well at your end.

What a belter of a photo! Now funnily this serves as a good example, all be it on a smaller scaler, as what not to do if self building or extending your house. I make some points. It's debatable. Technically to me it looks like a Universal beam, if you look at the flange width cf the web depth.. it look looks a beam, a column is more squat in profile. I can see from the photo the beam has buckled perpendicular to what seems to be a heavily loaded transfer beam at ceiling level. My gut feeling is that either the designer has made a massive cock up in calculating the loads on the, now call it a column. More likely is that they have not understood the top and bottom connections. They may have designed them as pinned, but then inadvertently introduced a stiff connection or some off centre loading ( called an eccentricity) that introduces a bending force in the column and not spotted it. This extra bending force reduces the capacity of the column to carry load. But on the other hand the Contractor may have thought they know better and just gone off and done their own thing. My experience of Contractors / project manager is mixed, I used to be a Contractor myself. Some think they know it all, some are arrogant in the extreme (pride comes before the fall) some are sensible enough to just make a call to the SE, which I now am. Now the photo is of a big building, heavily loaded. But when I design houses, wall slappings for extension etc the loads are much less, but I design with much smaller steels, thus pro rata they are doing just as much work. The design is lean. But if you listen to your builder without checking you are taking a big risk, don't be swayed by bravado, a builder telling you they know better. At the end of the day if the builder changes the design in any way and something goes wrong their insurance won't cover it, and possibly your home insurance won't either. It also critically unsafe. My advice is, if you want to deviate from your design drawings then call the designer, just lift the phone! IT'S THAT SIMPLE

Need ICs at changes in direction Gus……

Ok a bit of food for thought. You have a steel column, likely supporting a structural load. Let's say as a minimum you need some fire protection? Say 30 minutes. Now you can achieve that in two common ways. 1/ Box it in with say Gyproc Fireline board. Which probably gives you a detailing problem, which is why you are probably wanting to use Aerogel as it saves space. 2/ Paint the steel with intumescent paint. But for intumescent paint to work it needs to have space to expand into... you see the dilemma? As a rough rule of thumb the intumescent paint thickness needs to expand some 50 times to work properly. It needs space to do this. So you can't stick Areogell to the steel per say and you need manufacturer approval to stick it to intumescent paint. Now often BC etc don't pick up on this. But if something goes wrong, there is a fire, the steel fails and the building falls on say the Fire Brigade.. then the buck has to stop somewhere.. as an SE I'll be on the radar, Architect's also, and you if you have taken it upon yourself to become a designer then you are facing a huge liability. Now the above is a worst case.. but if you get a smart BC officer that knows about this stuff then they might be minded to fail your design unless you can prove otherwise. There are cases where the steel is well protected by masonry and very heavy and thick and thus possibly as at Paulie I think in Paulie's case the steels are so heavy they don't need fire protection. The load we use when designing steels for fire protection get reduced as they are called an accidental case. In lay terms we don't design most steels for the building being fully loaded up and a fire starting at the same time. I would go back and look at what your steels are doing, the loads and so on. Also have a chat with your SE to check if what you are proposing might invalidate their design for example. I appreciate you may not like this news.. but it's up to you and your risk.

I need some advice of some components to order for my external 110mm svp where it leaves the 1st floor bathroom on a masonry build. I'll have 2no. vertical lengths of svp with a 67.5° branch in the middle. The 117mm bathroom toilet core hole will have a 110mm plain pipe between inside and outside and then it will require an elbow, followed by 600mm horizontal section connecting the elbow to the svp branch. 1. Should the elbow be 87.5 or 92.5 and should it be single or double socketed? 2. I'm assuming one socketed end goes against the core hole to receive the pipe through the wall. If correct do you need to chase the external brick out some more so that the wider outside diameter of the socket end can be positioned part in to the wall and prevent it from sticking out away from the wall too much more than the bracket offset? 3. The horizontal pipe connecting the wall elbow to the branch will require plain pipe or a socketed end depending on single or double socket elbow. I wasn't sure if double socket is fine or its best to keep everything designed like a funnel by using the cut off socketed end from the 4m vertical svp if this makes sense?

Late to the party on this one, but I have spent a long time muddling through pan connector heights. I am guessing your original plan was to put a 90 swept bend into the swept tee and that would have made things too high. Or was it going to be a 90 degree pan connector straight into the soil pipe branch? Comfort height toilets can help, but not as much as 40mm I don't think. I think swapping to a 45 degree branch is a good shout from the not blocking perspective, but also would have lowered where the bend would have ended up had you gone that route (image below). With either branch option, you could have rolled the branch about its axis and used a 45 degree bend instead of 90 at the cost of pushing the pan further into the room a bit. Some other options to have on the thread in case someone else gets stuck like this. 45degree options: SP163 https://www.floplast.co.uk/product/bend-1 https://mcalpineplumbing.com/wc-connectors/rigid-wc-connectors/45-angle-rigid-wc-connector/ You can also get a tight radius 90 degree bend (OSMA 4S160B https://www.jewson.co.uk/p/osmasoil-pvc-u-spigot-bend-tight-radius-90-110mm-black-PO4S160B) You've ended up with a really nice result though, so it's all worked out well. Floplast parts shown (SP190, SP210, SP161).

Horizontal cylinder?

No need to add a second outlet, if it's a pain - just do two ducts to a single outlet 2x90mm to 125mm plenum.

Claude just stung me . Hit my 5hr limit early so bought more usage . Can see I’m using it - that’s fine . Then it stopped again saying I had reached my limit - which of course I hadn’t ! . Bought £5 more . Then got 10 mins then same again . Assume a bug . Emailed them ! Not much point to buying extra if you get blocked anyway !

Are you not supposed to do a lightbulb bend so you get a larger radius bend so no kinks but it still fits 150 pipe centres.

I haven't actually measured it, but it does feel cooler than the ambient temperature inside the house. I'm curious about this myself now, I'll put a temp sensor in one of the vent outlets tonight, and I'll let you know the results!

To answer this question, I thought I'd put it to Claude, using Sonnet 5 and this is the explanation 😁: Good instinct to probe deeper — the "logic vs pattern matching" framing is close, but it's worth untangling because there's actually a common conflation happening in how people talk about this. The big one: "reasoning models" (like OpenAI's o-series, DeepSeek R1, or Claude with extended thinking) are still generative models. They're the same transformer architecture, doing the same thing under the hood — predicting the next token based on learned statistical patterns. There's no logic engine, symbolic rule-checker, or formal proof system bolted on. So it's not really "reasoning vs. generative" as two separate categories — reasoning models are a subset of generative models, trained and used differently. Where the real differences live: 1. Training objective. Standard generative/instruct models are trained mostly via next-token prediction on huge text corpora, then fine-tuned to be helpful and follow instructions. Reasoning models add another stage: reinforcement learning on tasks with verifiable answers — math problems, code that either passes tests or doesn't, logic puzzles. Because the reward signal is "did you get the right answer," the model gets pushed toward generating long chains of intermediate steps that make correct answers more likely — things like trying an approach, checking it, backtracking, trying another approach. 2. Inference-time behavior. A standard generative model maps input to output in roughly fixed compute — one pass, token by token, no deliberation step. A reasoning model spends variable extra compute before answering, generating a chain of thought that's often much longer than the final answer. This is often called "test-time compute" — you're trading latency and cost for accuracy on hard problems. 3. What's actually emerging is learned deliberation, not logic. The self-correction and step-by-step structure you see in a reasoning model's output are patterns the model learned statistically pay off on verifiable tasks — not the result of a discrete symbolic reasoning process. It's still fundamentally pattern completion; it's just learned to imitate and refine the pattern of "working through a problem carefully," because that pattern correlates with getting rewarded. 4. Where each shines. Reasoning models pull ahead specifically on tasks where there's a checkable ground truth — math, code, formal logic, some kinds of planning — because that's where the RL signal exists. On open-ended, subjective, or creative tasks (write me a poem, what's a good gift for my friend), the extra deliberation buys little, since there's no "correct answer" to verify against. 5. What genuinely didn't change. Neither type has guaranteed soundness. Both can hallucinate, make arithmetic slips, or confidently reason to a wrong conclusion — because underneath, it's still probability, not proof. If you want actual logical guarantees, you need to pair a model with an external tool: a code interpreter, a calculator, a formal theorem prover. That's a genuinely different paradigm — classical symbolic AI (expert systems, SAT solvers, planners) — which really does manipulate symbols with explicit rules and can guarantee correctness within its formal system. That's probably the sharper "fundamental" divide you're sensing: not reasoning-LLM vs. generative-LLM, but learned-statistical-generation (even when it looks like reasoning) vs. rule-based-symbolic-computation. If it's useful, I could sketch a quick diagram contrasting the training/inference pipelines of the two approaches — let me know. Both paths share the same foundation — the same pretraining, learning the statistics of language from huge amounts of text. They only diverge afterward. The left branch is the familiar path: instruction tuning to make the model helpful and well-behaved, then inference in one fixed-length pass — you send a prompt, tokens come out, done. The right branch adds a stage: reinforcement learning where the model is rewarded specifically for landing on verifiable correct answers (math, code, logic). That training pressure is what produces the "reasoning" behavior — and it shows up at inference time as a different mode entirely: the model generates a long chain of thought, checking and revising itself, spending variable compute depending on how hard the problem seems, before committing to an answer. The thing worth sitting with: nothing in that right branch is a different kind of computation. It's the same token-by-token generation, just shaped by training to produce a "let me work through this" pattern because that pattern got rewarded. That's why reasoning models can still confidently reason their way to a wrong answer — there's no proof-checker in the loop, just a learned habit of deliberating that usually, but not always, tracks truth. Q. What is it that makes one model better at something like coding versus problem solving complex questions A few genuinely separate factors are stacked together here — it's not one lever, it's several: 1. How verifiable the reward signal is during training. This is probably the biggest one. Code has a built-in ground truth: does it compile, do the tests pass, does the output match. That's a clean, dense, automatic reward signal you can run at scale — write code, execute it, get a binary pass/fail, no human needed. Complex problem-solving (say, an ambiguous business strategy question, or a multi-step logic puzzle without a single "correct" answer) often doesn't have that. Even math and formal logic, which do have checkable final answers, don't verify the intermediate steps — a model can get the right answer via a flawed argument and still get rewarded. So coding ability tends to improve faster and more reliably under RL because the feedback loop is tighter and harder to game. 2. Data availability and density. GitHub alone provides enormous volumes of code paired with tests, comments, commit messages, and bug fixes — a rich signal for "this code was wrong, here's the fix." There's no equivalent firehose of "here's a flawed argument, here's the corrected reasoning" at that scale for general problem-solving. 3. Structure vs ambiguity. Code has strict syntax and (mostly) unambiguous semantics — a function either does what the spec says or it doesn't. Complex reasoning questions are often underdetermined — multiple defensible answers, judgment calls, incomplete information. Models trained hard on code get very good at satisfying a tight spec; that skill doesn't transfer cleanly to open-ended judgment. 4. Tool access changes the game. For coding, a model can be hooked up to an actual interpreter or execution sandbox, run its own code, see the error, and fix it — an external, ground-truth feedback loop at inference time, not just training time. For most "complex problem solving," there's no equivalent oracle to consult mid-answer, so the model is stuck relying on its own internal check, which is much less reliable. 5. What gets optimized gets improved. Labs benchmark heavily on things like coding benchmarks (SWE-bench, HumanEval) because they're measurable and commercially important. Effort follows measurability — so coding has had disproportionate optimization attention relative to fuzzier reasoning domains that are harder to even define "correct" for. The upshot: it's less "this model is smarter" and more "this domain gave the training process a cleaner signal to learn from." A model can be excellent at code and mediocre at ambiguous judgment calls precisely because one of those had a built-in answer key and the other didn't. There you go, hope that helps 😁

Makes sense to drop the pantry supply and add 2nd outlet in lounge. Its a warm roof & the room extract/supply ductwork should be under the loft boarding but good point on avoiding summer heat gain. I had put the extract/supply on the north facing wall - south facing is all glazed (with decent overhang, triple glazing etc) - could put it through the east facing roof as alternative. I agree its busy round the coat/pantry area - I'm for dropping the coat door but some negotiation with SWMBO needed... Will look at headroom and DHW cylinders as agree it would free up a chunk of space. All very helpful thanks

I can also run the bend in an offset position, as in not perpendicular to the direction it's heading, that way most of the bend radius can be lost in the upstand. Hard to explain, I know what I mean LOL! I'm just downloading that vid down my copper telecoms line, be right back!

Actually reading through the list, I'm thinking of applying for pumped hydro using coal gas or peat fuelled steam turbine and then storage using either diabatic compressed ammonia or zinc bromide batteries. Maybe a little less than 50MW.

Not sure but it may be to do with condensation aliveation.

Really helpful. I guess it depends what you are using the model for; but for me opus 4.8 is destroying gpt5.5 for coding in my experience. I mean they have codex. If I get that to 'scout' it can take a minute+. Yet claude (git is local in both) takes 20 seconds, explains the code and proposes patch. Codex was never that reliable. Codex suggestions for patch I dumped back into gpt5.5! - it usually said they were wrong. But the claude "I can open a preview" and agentically fix the issue is AMAZING. i guess the claude environment is just far easier and cleaner for me than my attempt to harness gpt5.5. I did ok for 20 quid a month mind for quite a while.

Looking again now it's simplified the pantry supply isn't really adding to anything. The plant room extract is drawing air through that room anyway. Having the supply causes a short cut from pantry to plant room. Do double 90mm duct to lounge, everything else should be fine in single 90mm ducts. If in loft you will need insulation on ducts. Or build a PIR tunnel for the ducts. Build the MVHR into an accessible insulated box to stop heat gain in summer and cold in winter. Loft hatch will really need to incorporate a ladder for access. Floor loft for access to allow filter and general maintenance to MVHR. MVHR will need a dry trap for condensation drainage. Since you have moved the MVHR is there any reason not to move back to where it was and take the inlet outlet out the other end of the building by diner. Then all the possible noise is well away from bedrooms. Observation pantry seems to take up a lot of space for effectively a corner cupboard and what is the appliance garage? I would look to simplify the pantry, appliance garage and coat store. You have 4 doors in that area which is very busy. Do you need a plant room? Cylinder is making space too much of premium, you have loads of dead space in the loft, your MVHR is there already. Assume you have a heat pump UFH manifold could go in the utility where the cylinder is shown. Then have a more usable utility.

"Just make one model that follows the green line, not 3 models where I have to work out which to use when and on which settings, and guess which will be more token efficient..."

(0) For 'fun' make an account and look at HV & LV resources in your area together with unutilised capacity. Hope that it's shown in green: Network Infrastructure and Usage Map (NIUM) — UK Power Networks

they become brick slips or hardcore easily. I agree it is wasteful.

Highly unlikely you will have any problems unless there are adjacent buildings where the height would be noticed. If just using FFL, you will (could) be bringing landscaping up at the end of the build so height will still be relative

Been reading without comment as I don't know aerogel. But my inclination is to keep it simple and ensure a good, solid and permanent connection. What area of steel are we talking about, relative to the wall area? i.e. is it the biggest deal to get maximum insulation? And what depth is available? There are several makes, too and its available at my local BM (and yours) , Topps and at Wickes, so about £30/m2 and no transport cost. Depending on detail and access, I'd probably stuff the void of the steel to stop that cavity being cold, and also reducing overall heat loss.