And in case people think ultrasonic signaling isn’t a real thing, it very much is. In the oil and gas industry, it’s how measurements taken while drilling a hole are sent back to the surface through the drilling mud.
Downhole tools used in MWD/LWD do not use ultrasonic frequencies. Drilling is a very noisy environment. The first tool that I used employed a downhole pulser with a surface transducer and operated at about 0.5-1 Hz. That's not ultrasonic. It was a pretty low frequency signal. Data transmission rates limit the volume of information that can be transmitted from the downhole tool to the surface where they are decoded.
Your tool has to set up a pressure wave in the mud column that is detectable miles away from the tool while the well is being drilled.
This is a good recent paper authored by an experienced drilling engineer about MWD/LWD drilling history and pulser designs and data rates that can be expected.
Boy how I wish it had used ultrasonic frequencies. Sadly enough though, I spent large parts of every day in front of a laptop connected to a transducer waiting for signals to appear in the noisy stream of data coming from the standpipe transducer. Every few seconds if your tool still functioned you would get the first bit of a signal that contained toolface orientation information and gamma ray data if you had a gamma ray sub. It was a binary stream of ones and zeroes where a 1 was a pressure increase and a zero was a decrease to background. You needed to be quick on the decode because the directional driller on the rig floor was using the real-time toolface orientation to help steer the drill bit to the target formation and on to TD (total depth).
As the days went by and the hole was progessively deeper it was inevitable that some part of the downhole BHA (bottom-hole assembly) would fail due to erosion from the drilling mud, erosion at the bit/formation interface, friction along the borehole wall, etc. The hope was always that your tool would function well enough until something else failed and necessitated a round trip to replace a critical component. The costs of the round trip were placed on the service company that had the failed equipment so even if your company supplied the MWD/LWD services and the directional drilling services (DD), if your tool failed the cost of the trip fell on your service and impacted your service quality assessment which affected your rig bonus calculation.
It was common for a DD with a failing mud motor to hang around the MWD shack or keep the MWD engineers on the phone, harassing the engineers to get them to admit that their tool is nearing the point where the toolface data was so low level that it was undecodable. If he could hang the trip on the MWD he would every time so the MWD engineers were incentivized to struggle through poor signal for as long as possible when they knew from the pressure data that the mud motor was about to crater or that the drill bit needed to be replaced.
Battery failures and erosion of the pulser valve components that resulted in signal amplitudes diminishing to the point where they were undetectable were the things you knew would happen and you just hoped that downhole conditions killed someone else's tool before yours inevitably failed.
I had to read a little since I had not checked on their progress in a while.
First, I like the backgrounds and experience levels of the key personnel in the company. Many are oil and gas industry veterans with a good mix of skills - drilling, deviated well design, fracking, downhole monitoring sensors, etc.
DAS deployed downhole as their paper describes should give excellent information about conditions near the boreholes as they pressurize and depressurize the formations through the enhanced fracture networks. Induced seismicity is a common side effect of fluid injection and anyone who has watched USGS earthquake data for California has likely identified the geothermal fields by their frequent seismicity. Reducing the levels of induced seismicity related to geothermal energy production will decrease the likelihood of formation damage due to accumulated stresses in the production field. It sounds like they are able to tie specific stress/relaxation events to pressurization events so that is a very useful tool.
A lot of the earthquakes in the Permian Basin area are related to fluid injection. A DAS network could possibly mitigate some of that so a technology transfer back to the O&G industry may benefit all of us.
I agree with their goal of expanding geothermal energy production as an integral part of the power generation grid since, like they say, it is completely renewable. It does take advantage of downhole conditions in order to produce the energy and there is an opportunity to utilize existing boreholes as geothermal generation sites after the oil and gas becomes uneconomical so it could give new life to old fields and preserve jobs in the area since there will already be a trained workforce locally.
Pretty interesting. I lost track of these guys and now I see that they IPO'd a couple months ago. I expect that their business and their competition will both be increasing over the next few years at least.
John Regehr tried to start an initiative to make what he called Friendly C, removing some of the most blatant C footguns, and even that turned out to be extremely hard to get consensus on: https://blog.regehr.org/archives/1287
If I had to guess, they probably have some ideas. In Your inner fish (an excellent book, BTW) Neil Shubin has an afterword where he describes roughly how they went about deciding where to look for Tiktaalik. Basically, you start with whatever thing you want to find out more about; in the case of Tiktaalik, the transition of tetrapods from aquatic to terrestrial living. So you start by finding out where you have exposed sedimentary rocks of the correct age likely to be contain fossils. Next, you also need to the rocks to expose the right kind of environment: desert sands or deep ocean environments aren't going to help you find Tiktaalik, for that you need shallow waters and intertidal zones. Finally, it needs to be somewhere you can get to. So in this case, I wouldn't be surprised if they were purposefully looking for soft body preservation (especially since I think Cambrian fauna generally was quite soft and squishy).
From memory, to get fossilised soft tissues you want the remains to be buried extremely rapidly in an environment where the soft tissues don't decay (typically an anoxic environment, so for a shale basically covered in mud). So a mudslide is one option, and I think there are some lovely fossils North American from the end of the Cretaceous that are hypothesised to have been buried by the tidal wave caused by the Chicxulub impact.
Edit: After some googling, the Cretaceous fossils I was thinking of is Tanis,[0] which is in fact plausibly (but not universally) thought to be covered by the earthquake caused by the impact, before the tidal wave arrived.
I worked as a Smalltalk developer for a few years, and it spoiled to such an extent that I’ve tried to make an extension for IntelliJ to replicate the browser for Java development. Maybe I should revive that project, actually…
The core system at my previous employer (an insurance company) worked along the lines of the solution you outline at the end: each table is an append only log of point in time information about some object. So the current state is in the row with the highest timestamp, and all previous stars can be observed with appropriate filters. It’s a really powerful approach.
Yeah, basically. The full system actually has more date stuff going on, to support some other more advanced stuff than just tracking objects themselves, but that's the overall idea. When you need to join stuff it can be annoying to get the SQL right in order to join the correct records from a different table onto your table of interest (thank Bob for JOIN LATERAL), but once you get the hang of it it's fairly straightforward. And it gives you the full history, which is great.
Sounds cool! Do you keep all data forever in the same table? I assume you need long retention, so do you keep everything in the same table for years or do you keep a master table for, let's say, the current year and then "rotate" (like logrotate) previous stuff to other tables?
Even with indices, a table with, let's say, a billion rows can be annoying to traverse.
I wasn’t involved in the day to day operations of the system, but it had records going back to the 90s at least I think. I think data related to non accepted offers were deleted fairly quickly (since they didn’t end up being actual customers), but outside of that I think everything was kept more or less indefinitely.
Lichess uses a scheme which is probably more efficient on average, described on revoof's blog[0]. Basically, it's a variable length scheme where the first 64 bits encode square occupancies, followed by piece codes (including castling, side to move, and ep with some trickery), followed by half-move clocks if necessary.
It also can encode chess960 positions. With the article's encoding, uncastled rooks can only be decoded if their starting position is known, which it isn't in chess960.
It’s mathematically dissatisfying, but often the most optimal storage (or algorithm) solutions involve clever heuristics that are dynamically applied.
Some systems just have to be observed in order for solutions to be optimally designed around how they actually behave, rather than how they theoretically behave.
For about two and a half years I worked on a Smalltalk system, written in a quite old Smalltalk, which gave me two idiosyncrasies editor-wise: I no longer care very much about syntax highlighting (though I don't really bother to turn it off), and I now prefer to use proportional fonts for my programming. The only syntax highlighting I missed in the Smalltalk was a fading out of comments (which would in fact have prevented a stupid issue similar to the comment thing shown in the OP).
Good PBT code doesn't simply generate values at random, they skew the distributions so that known problematic values are more likely to appear. In JS "__proto__" is a good candidate for strings as shown here, for floating point numbers you'll probably want skew towards generating stuff like infinities, nans, denormals, negative zero and so on. It'll depend on your exact domain.
I'm pretty sure the publishers are alleging that a crime has been committed. In that case, private parties can't open a suit (at least if Swedish criminal law is at all similar to Norwegian law), so this asks the police to open a criminal investigation into the matter. What happens next in the Norwegian system at least is that the police will conduct their investigation, and at some point when the police consider their investigations complete the prosecutor's office will decide what to do next. Next steps can be concluding that no crime has occured, to ask the police to investigate further, that a crime has been committed but the evidence are insufficient for a trial, or that someone should be tried.
Surely you can still sue separately through the civil process even if you choose to not pursue criminal charges?
If someone causes you damage through non-criminal negligence, surely you can sue them?
The idea that you couldn’t bring a civil suit over possibly criminal conduct seems unworkable. It’s possible that my neighbour was drunk when he crashed into my parked car late at night, but surely that can’t preclude me from seeking compensation through civilian courts.
It’s possible, but tremendously unlikely that Facebook is committing fraud here. In Sweden you have to prove intent to defraud, which is a tremendously high bar.
Which, again, makes the idea that you couldn’t bring a civil suit seem ever more bizarre. How could you possibly know if Facebook has committed fraud here? You presumably can’t read Zuckerbergs toughts.
In that particular example (drunk neighbour damaging your property with reckless driving) is really — in most of Europe, I would guess as Serbian laws are largely copied over from different EU country laws — handled by the insurance.
Basically, insurance against damage to others is obligatory for anyone to get the car registered and on the road.
If someone drives an unregistered, uninsured vehicle, a consortium of all insurance companies pay for the damage, and sue the perpetrator in a civil case.
In general, you can argue your level of damage with the insurance company, and can even take them to court.
In Serbia, drunk driving actually precludes the liability of the insurance company too, but they still need to pay out the damages first, and bring a civil case against the driver to get compensated. For that, they need a criminal conviction.
(I've had the unfortune to be hit by a drunk driver, luckily no other harm than to the property as both cars have been totalled, and his insurance argued a lower value for my almost new car)
I am guessing here the "intent" can also be "aware of it but did not invest enough to curb it while it is profiting off it".
Yeah, I know how car insurance works and just figured it’d be overly verbose to specify some scenario where the neighbour was driving some uninsured vehicle like a tractor and the incident happened outside of public roads.
I do think I still managed to make my point though, preventing civil lawsuits arising from possibly criminal behaviour is unrealistic. That would make it extremely difficult for individuals to seek compensation for almost any damage they might suffer, they’d have to first wait for months or years before the police gets back to them.
>I am guessing here the "intent" can also be "aware of it but did not invest enough to curb it while it is profiting off it".
Fraud by negligence is a fairly exotic concept and to my understanding usually specifically relies on laws regarding negligent misrepresentation. I’d be surprised if that would work in Sweden.
>For liability for fraud to come into question, the prosecutor has to be
able to prove that the crime is deliberate. This means that the criminal
act has been committed consciously or intentionally. Liability for fraud
is conditional on the objective requisites being covered by the perpetrator’s intent. It is not possible to judge a person to be liable for fraud because someone has been paid too much compensation as a result of negligence, or because the person did not know about certain obligations in
conjunction with the compensation. Carelessness is thus not sufficient.
It must be possible to prove that the perpetrator has committed the act
intentionally. This intent must cover all elements of the criminal act.
The great problem with fraud crime is to prove the intent. The actual
circumstances surrounding what really occurred are often a lesser pro-
blem. The assessment of the intent is complicated by the fact that the
rules concerning social insurance can be difficult to understand.
The difficulty in proving intent has meant that several assessors have
considered that the fraud regulations do not work quite as they should.
Proposals have therefore been made that negligence should be sufficient
for judging that a person has misled the Social Insurance Agency or
some other payment-issuer within the compensation and benefit systems
(Örnemark Hansen, 1995). This criticism against the intention require-
ment has led to the new Benefit Crime Act (2007:612).
Generally legal system has negligence, and once someone is provably informed of the negative consequences but keeps being negligent, "willful negligence", which is much closer to intent (I see it defined as "intentional disregard...").
IANAL, but common sense tells me there should be a link to willful harm.
I found the Smalltalk way of working in the running environment to be very programmer efficient too, and that it was by far the smoothest development experience I’ve had, even in a pretty dated and clunky Smalltalk at that point. And debugging wasn’t really a problem in my experience, but we stored application state outside of the image in an SQL database (initially Sybase, then MSSQL), which probably removes some «haha, the image has some weird data saved in the dark and dusty corners» issues.
