mhagdornOur paper "Future challenges for Research Software Engineering" is out. We looked into what research software engineering might look like in future and what challenges will await us. The paper is based on a community discussion during the deRSE 2025 conference.
US Research Software EngineersThe #NAIRR pilot has evolved from concept to a real shared #AI research platform that connects researchers, educators, industry partners, and national labs. Sandra Gesing, executive director of US-RSE, highlights how this 2-year-old collaborative infrastructure is lowering barriers for teams to fuel creativity, discovery, and possibility.
👉 Read more: https://www.govtech.com/education/higher-ed/2-years-into-nairr-pilot-shared-infrastructure-boosts-ai-innovation/
#RSE #RSEng #ResearchSoftwareEngineering #Innovation #Collaboration #HPC
Andy TsengThe @[email protected] team at @[email protected] is fantastic and has some amazing job openings! Please share this with anyone who might be interested.
#HASS #RSE #DigitalHumanities #ResearchSoftwareEngineering #UniMelb #JobOpening #Recruiting #Hiring #ResearchSky #AcademicSky
RE: https://bsky.app/profile/did:plc:wks7m2r2wtveh4nzyw4hsocs/post/3m5xgkeoi6k22
RE: https://bsky.app/profile/did:plc:wks7m2r2wtveh4nzyw4hsocs/post/3m5xgkeoi6k22
David WyldCan anyone help me find a new server?
I've recently changed my surname and since I want to create a new mastodon account to match, it's a good time to also find a server that might be a better home for me than Fosstodon.org
TBH, I don't use many of the within-instance features, mainly I just look at feeds of people I follow, but I can't be bothered to self-host.
I'm mainly interested in toots about #RSE (#researchsoftwareengineering), #environment, #maker stuff - so maybe there's no best fit!
Strathclyde's RSEOur next Hacky Hour will take place Wednesday, 1st October 14:00-15:00. We will meet in the Learning & Teaching Building on in the Union Bar fake lawn. Our Hacky Hours are informal meetings to help with programming problems and related issues (testing, documentation, maintainability, reproducibility). We have experts in programming languages, command line shells, collaborative tools, LaTeX, a number of scientific fields. https://www.strath.ac.uk/science/computerinformationsciences/hackyhour/ #HackyHour #RSE #ResearchSoftwareEngineering
arclightA more complete example would involve a mechanical desk calculator, a slide rule, and mathematical tables like Abramowitz and Stegun ("Handbook of Mathematical Functions") https://www.nist.gov/mathematics-statistics/handbook-mathematical-functions-abramowitz-and-stegun Prior to the use of digital electronic computers, complex numerical problems were translated to manual computing plans and solved by teams of human "computers", often women with degrees in math who were locked out of university and technical jobs.
This is sort of the origin of #researchsoftwareengineering - the relationship between subject matter experts who understand a problem domain and the pure and applied math underpinning a solution and the experts in numerical analysis and computation who could convert that mathematical solution into a plan or program suitable for automatic computation whether the computer was electronic or human.
I'm mainly interested in the evolution of digital computing techniques here but it would take very little to make this a complete example that covered all of 20th century computing and broaches some very uncomfortable facts about gender and race in computing long before ENIAC. Not my primary focus but I'd feel remiss in not calling it out.
I swear I'm going to get thrown out of the #researchsoftwareengineering community before I actually get into it. I'm not setting impossibly high standards - "show your work" is standard in every branch of math, science, and engineering. Just apparently not when scientists and engineers touch computers.
Stephan Druskat📢 "#ResearchSoftwareEngineering: Discovering and Bridging Knowledge Gaps" is out now in IEEE Computing in Science & Engineering: https://s.dlr.de/cise-special-issue-rseng.
This special issue collects work that has been started during the #Dagstuhl Seminar 24161 "Research Software Engineering: Bridging Knowledge Gaps" (April 2025): https://dagstuhl.de/24161.
Over 5 papers, it lays out how #RSEng and #SoftwareEngineeringResearch should collaborate in the future for mutual benefit.
#RSE s can leverage state-of-the-art methods and tools from software engineering research to create better software that enables better research. SERs can gain insights into an understudied area of SE practice, and develop new research questions and agendas that produce the methods and tools required for state-of-the-art software engineering in research contexts.
The issue has been guest-edited by @danielskatz, Caroline Jay, Lars Grunske and myself.
🧵 The following thread posts present each of the collected papers.
Our next Hacky Hour will take place Wednesday, 3rd September 14:00-15:00. We will meet in the Learning & Teaching Building on in the Union Bar fake lawn. Our Hacky Hours are informal meetings to help with programming problems and related issues (testing, documentation, maintainability, reproducibility). We have experts in programming languages, command line shells, collaborative tools, LaTeX, a number of scientific fields. https://www.strath.ac.uk/science/computerinformationsciences/hackyhour/ #HackyHour #RSE #ResearchSoftwareEngineering
One of the unresolved nagging challenges of engineering analysis software is setting and verifying code accuracy at a gross, usable level. Something like stating the code will calculate temperature within ±5% or some fixed band of uncertainty or error. Formal software quality assurance (SQA) asks that expected or guaranteed accuracy be documented and verified but I'm always at a loss at how to actually do that. Very often codes make no firm guarantees or claims and as a code author, making an estimate or guarantee seems an intractable task. Formal error analysis is difficult enough for simple analytical expressions; add sophistacated numerics along with empirical correlations and the whole effort seems impossible.
This isn't a new problem - it doesn't seem to have gotten any easier or better than when I took my first numerical analysis class in the late 1980s. Since then I've discovered interval arithmetic and symbolic execution systems like KLEE https://klee-se.org/ but these are still off in ths weeds of research and basically unknown to those creating production code, either to practitioners writing Fortran or Python or in any of the commonly available software tooling (VSCode, etc). I don't know if usable tooling even exists or where to look for it if it does - the communication pipeline from software engineering research to practice seems small to nonexistent.
It's more thsn a little frustrating that such a vast amount of money and attention is sluiced at making non-deterministic unverifiable systems marginally more believable (and nowhere near as trustable or useful as our current traditional deterministic systems) while we still seem to have no better way of answering fundamental questions or making reasonable claims about the accuracy of the codes we trust every day for performing mission- and safety-critical engineering analysis. Looking at a year's worth of CACM articles, it doesn't seem that making numerical software any more trustworthy is on anyone's radar and whatever work is being done in this area (I'm assuming there's some) is completely unknown to those of us working at the coal face of engineering software development and QA.
Am I missing something or is the situation as bleak as it appears?
#researchsoftwareengineering #rse
This isn't a new problem - it doesn't seem to have gotten any easier or better than when I took my first numerical analysis class in the late 1980s. Since then I've discovered interval arithmetic and symbolic execution systems like KLEE https://klee-se.org/ but these are still off in ths weeds of research and basically unknown to those creating production code, either to practitioners writing Fortran or Python or in any of the commonly available software tooling (VSCode, etc). I don't know if usable tooling even exists or where to look for it if it does - the communication pipeline from software engineering research to practice seems small to nonexistent.
It's more thsn a little frustrating that such a vast amount of money and attention is sluiced at making non-deterministic unverifiable systems marginally more believable (and nowhere near as trustable or useful as our current traditional deterministic systems) while we still seem to have no better way of answering fundamental questions or making reasonable claims about the accuracy of the codes we trust every day for performing mission- and safety-critical engineering analysis. Looking at a year's worth of CACM articles, it doesn't seem that making numerical software any more trustworthy is on anyone's radar and whatever work is being done in this area (I'm assuming there's some) is completely unknown to those of us working at the coal face of engineering software development and QA.
Am I missing something or is the situation as bleak as it appears?
#researchsoftwareengineering #rse