“A lot of folks directly involved in fighting have other things to think about.”

Well, didn’t get much writing done today. Slept for about ten hours, got up, ate, then slept some more.

I did manage to run into something interesting on how data is being collected and used here. Obviously in a combat situation the collection of data is a bit problematic, since a lot of folks directly involved in fighting have other things to think about. But it is being done. Obviously some of the stuff we see and record is a part of that, albeit a small part. It seems the collection of data started prior to their being any kind of large plan per how to use it. The use then was very specific, mainly how to improvise existing systems to meet the Russian onslaught.

That changing threat seems to be at least a partial impetus toward a more focused effort to gather data for processing and interpretation. The other factor is undoubtedly a very high interest in the west in the methods the Russians use to meet the changing Ukrainian threat, how they manage it, and the speed and efficiency of their implementation. This is especially crucial when it involves western equipment.

I knew of this interest some time ago, as it was expressed by some of my informal contacts in the US Mil and Gov. At some point there was a question whether or not the Russians had the capability to respond to the improvised systems fronted by the Ukrainians in their dire need to use what they had to fight as best they could. But, in time they did mount a reasonably workable response against some of these challenges—mainly drones, the capability of which was degraded by an increased Russian use of drones, both for detection and directional jamming. This proved more efficient than their mass area jamming, which degraded their own drones almost as much as it did Ukrainian ones.

At this point, the Russians are still falling short of dealing with many of the systems the Ukrainians have in use, a few examples being land and naval bases drones, as well, as the Ukrainian’s ability to evade Russian air defenses. The latter is of high interest to the West.

The methods being used to collect this data are wide ranging. It involves pretty much every dot they can collect, from situation reports, to drone footage, oral interviews, and satellite data provided by the west. It is a typical big data approach. I am not informed of the methods they are using for interpretation, but assume it utilizes the standard tools for such, which will likely involve AI at least for logic testing the data if nothing else. For those who feel that AI is largely hype (and nowadays there is a lot of that) we were using earlier forms of AI decades ago to help construct models for nuclear weapons, one of the most important uses being predicting workability of air lensing designs based on optical quantum efficiency sub-models. Be that as it may, it goes without saying that this kind of operation involves substantial computer power and programming expertise. It would be nice to know how much, if any, the West is contributing here.

Assuming they can collate all the data and analyze it, and continue to add to it as things on the battlefield change, then the challenge will be to make the correct assumptions and thus some statistical predications that might allow them to be proactive against the changing threat. And then the really hard part is putting it to use in the field, and the timing of doing so.

It is an interesting endeavor for sure, and one I wish I had more specific information on. We were mainly being advised as to the data needs, but I did manage to cajole a bit more out of the folks giving the briefing, although it was clear their own knowledge was somewhat limited as well.

One specific thing that came out as an aside with a few mil engineers was the modification of cheap optical devices (off the shelf cameras) to allow monochrome and IR detection. This is something I know a bit about, and have a lot of interest in. It was a very detailed discussion. To summarize, it involves removing the IR filter over the camera sensor (as well as a UV one), and in many cases removing the Bayer filter on the surface of the sensor, which involves physical scraping, chemical (photoresist stripper or a solvent combination) or laser removal. It is more complicated than that, since you will lose the microlenses, thus hurting the light gathering efficiency of the pixels. But, at the wavelengths involving IR, those lenses are very inefficient anyway, so with a good lens and a quality sensor, you can make up for it. The real problem is the way you have to treat the images in software, which involves producing raw files from the camera, and massaging them in post. The processing engine in the camera assumes color, so treats the monochrome/IR image as color. And to add to that, raw images are huge, so is a challenge to provide them real time. Not good. Anyway, I could go on about this all night, but will assume interest is limited in the down-and-dirty details.

So that was largely my day. Today I am going to hit my daily diary thing and get that down. We saw more action than is usual this time out.

---

(A conversation with several people.)

So Chris, Ian, Carlos and Antin all have low grade blast wave concussions.

And yourself?

I decided to sleep and drink instead of trudging down to the quack. Headache is gone, eye sprites are gone, so I figure I will live.

---

Been talking cars on DMs, and an interesting engine to point out is the 1990 ZR-1 Corvette engine, the LT-5. An all aluminum engine designed by Lotus, and manufactured by Mercury Marine. How weird is that?

Of course the new C8 with the flat crank engine is also way out of the norm for Chevy.

One of the best marriages ever was the Otto cycle gasoline engine and computers. Back in the day, gas engines were very inefficient, and if you got 100k miles out of them without a rebuild you were lucky. Materials made a difference, models (computers again) made a difference, as well as did lesson’s learned. But computer engine management was the elephant in the room.

But that took some time to make work. When General Motors brought in Intel to try to develop their system, the development engineer from Intel was freaked-out by what they did to his computer board…

“First rattle out of the box they put it on a test stand and shot giant lightning bolts at it, frying the damn thing.”

Now, you can get a small displacement engine, low weight, high horsepower and torque, that will get 25 MPG, and last 250k miles. And, it runs smooth through its duty cycle.

Kinda the same with nuclear weapons. Yields and effects did not become reliable and repeatable until computers came along with enough capacity to do modelling. And, that also took a while to get worked out. Fuzzy logic, a sub-type of AI, was used extensively, but it could not deal well with the very complex formulas required to model a nuclear burn, so new forms were developed that could integrate better from the analytical to the numerical.

I looked at some of the early models for secondary burn, and the delta span was so wide it could predict results from -x1 to +x20 of primary trigger yield. Of course, the designers knew better than pay attention to those results.

In the modelling era, most fizzles were the result of trying to design ever smaller yields, and trying to highlight effects as opposed to explosive yield. Higher than design yields (blow-outs for a primary, runaways with a secondary) were designed-out for a very specific reason…they had to be tested. By this time designers had a reasonable understanding of equations of state, and learned a lot from their underdesigns for yield test safety. All of that went into a database, and if we were designing new weapons today, would be a part of the matrix models.

Modern weapons design models are made-up of many different modules. Each module can be re-crunched based on output spans. The variance on them are capped based on limits set by systemic knowns. If you get something weird, you either fucked-up on your design assumptions, or you are onto something out of the model learning experience —good or bad.