I would argue that in your case functional programming is actually more suited than OOP since what it boils down to is a set of operations process on "blank" materials that results in a new material, well actually the same with different properties.
If I was restrained to OOP I would create different classes :

MaterialType which is basically a string or enum (of a, b & c)
ExternalProperties for temperature/pressure, etc.
Material which contains the Material_Type and various properties/functions aimed at transforming the material type so for instance it could contain a transform function with an unbounded list of ExternalProperties
Laboratory to do all the operations

Here object c would be the MaterialType which the Material can calculate without inheriting of everything else.
It's hard to propose an accurate concretisation since your example is very abstract but I think inheritance brings more problems than solutions here.
I am relatively new to oop and had a quick question about the best way to approach coding a certain type of calculation. I'm curious if there's an established design pattern to approach this sort of problem.
Consider a chemical process flow where you convert materials (a,b) with attributes such as temperature, pressure, flow rate, etc. into a final product c. To get there, I need unit operations D,E,F... each with its own set of attributes (cost, size, etc.). I would only need information flow in one direction as closed loops will probably increase the complexity (if not, I would really appreciate insight into how closed loops would work).
a,b --> D --> E --> F --> c
Ultimately I would like to be able to do a system cost analysis, where I would sum up the cost attributes of D,E,F.
My current thought process to approach this is to define a "materials" object, then have D inherit materials, E inherit D... c inherit F then lastly a "system" object inherit c to analyze the system variables. Since I would like to be able to swap out D,E,F for say G,H,I, there also needs to be code for conditional inheritance where D must be able to accept inputs a,b (based on defined attributes) and E be able to inherit D for the same reason. One of the things I'm unsure of is how object c would be able to understand how to sum up attributes of all the inherited objects (probably based on some consistent naming convention of objects/attributes?).
Sorry for the somewhat lengthy question - if you are aware of AspenPlus, I'm looking to replicate a smaller scale version of this (ie no solvers) in Python. Thank you for reading through this!
Python OOP Design Pattern for Calculation Flows